Hacker News Reader

Comment by zozbot234 | Hacker News Reader

I don't understand why the TUI of old text-mode IDE's (from Microsoft as well as Borland) has yet to be replicated in modern terminal environments. You can kinda get a menubar in Emacs but it's quite clunky, and grabbing mouse input in the terminal requires a separate incantation. And even Emacs doesn't allow for floating windows/dialogs, nor does it show text-mode scrollbars or windowing widgets.

You'd think that many devs would want something like this, to code via SSH while logged on a remote dev system, or perhaps from a mobile device app. Is it really that hard?

View on HN

The IBM PC text mode buffer was mapped into memory, so you could quickly update any part of the screen and easily do things like double-buffering (for rock-solid screen updates), composing the screen out of floating windows held in separate memory buffers, etc.

The Unix terminal is derived from line printers (teletype), a fundamentally different kind of TUI.

I don’t know how much this realistically affects today’s terminals since we have extremely fast connections. But it’s the original reason why those DOS text UIs had such a distinct snappy feel.

There are some *nix programs with complex TUI's, where a "snappy feel" is sought after (e.g. the `aptitude` TUI for package management in Debian and its derivatives) and they're just as snappy as any old DOS app. The overhead from using a terminal-based API is just too low to matter.

As it ought to be since the lowliest Raspberry Pi is tens of thousands of times faster than the IBM PC. Filling a screen shouldn’t be an issue regardless of the protocol in the middle.

But design decisions made in the 1980s still linger in a lot of Unix software.

This is exactly correct.

As far as affecting the state of TUI/CLI programs today, it becomes part of the culture as well as part of the overall look and feel of the system.

Yet, there are programs that break from convention: JOE, Dit, irssi, etc.

Still, back on the Slackware 2.0 days there were plenty of TUI applications.

Here for the younger generations, https://en.wikipedia.org/wiki/Ncurses

I think it is partly fashion (little UI is more "hackerish" after all) and partly lack of exposure (a lot of programmers nowadays who have worked on TUI applications might have little to no exposure to DOS programs of yesteryear).

It is technically possible though, as an example here is Free Pascal's text-mode IDE[0] running inside an xterm window under Linux. The IDE uses Free Vision[1], a TUI framework originally based on Borland's Turbo Vision, that is nowadays part of Free Pascal itself (though the framework uses the TP7-style "object" types for OOP instead of the Delphi-style "class" types).

[0] https://i.imgur.com/QZWt9lC.png

[1] https://wiki.freepascal.org/Free_Vision

Yeah but FPIDE is the exception that proves the rule. Why can't we have a VSCode work-alike in text mode, with LSP, tree-sitter and DAP support? That stuff is even getting added to Emacs these days, so it has a proper free-software pedigree even though it comes from M$.

Isn't that neovim, emacs -nw and helix?

emacs -nw?

There are some. One of my favourites is Terminal.Gui[0], but you have to be in the .NET world in order to use it.

[0] https://github.com/gui-cs/Terminal.Gui

> And even Emacs doesn't allow for floating windows/dialogs, nor does it show text-mode scrollbars or windowing widgets.

However, the floating window had its downsides. They hid what was behind the window and modals, so if you started a dialog box and changed your mind about the text behind it, you have to close the dialog box, change the text and restart your dialog box.

Emacs and Vim avoid these problems by turning everything into a buffer. So all of your interactions with the editor are done through buffers which can be opened side by side.

There are attempts at similar things - https://www.willmcgugan.com/tag/textual/

Interestingly, menues and scrollbars are the first things I turn off on new Emacs installs.

Reply on news.ycombinator.com