This is a pointless semantic argument.

Of course you can use the primitives of TUI, especially with mouse support, to reproduce a large amount (if not all) of the standard GUI interaction paradigms.

But it's bizarre, and missing the point from a UX perspective.

As an extreme example, we can imagine a program that displays the borders of a 40x15 "window" in the middle of a console, with box-drawing characters, putting a "close box" in an upper corner, with text like "File Edit Help" in the top left. We can imagine it responding to a click on the "File" text by popping out a "menu"; we can imagine a drag starting from the "title bar" causing the window position to be update (and the entire terminal window redrawn).

A lot of those kinds of functions, ironically enough, might make sense for a TUI editor implemented as a TUI (except the "windows" might just be understood as panels where the ultimate program displays parts of its output). But as an emulation of GUI windows, it'd be a strange, impractical novelty.

I've been using TUIs since PR1MEOS mini-mainframes in the early 1980's, I know what I'm talking about.

The issue is not the text. It's the WIMP interface.

I assume his point is that making stuff that assumes a mouse makes for a bad text-based UI. Absolutely fine if everything is controllable via the keyboard, e.g. if the tabs were labelled F1-Fn and they function keys switched them, or they had an underlined letter and Ctrl+letter switched focus to it, or whatever.

But if this thing requires you to just tab a lot through lots of pointless and rarely used fields to get to a "button" so you can activate it, because it's really all designed to be used with a mouse, then it's a bad text-based UI.

There are some incredibly good text-based UIs around, some going back to mainframe stuff from the 70s. Most of them are optimised for speed of control via keyboard rather than for looking pretty. Almost none of them would be quicker to use with a mouse.