Thomas Dickey

Of course, one could phrase the question the opposite way. Many people have, over the years.

> After all these decades, Unix and Linux people are still limited and encumbered by the antique typewriter-mode way of interacting with a computer?

This sword cuts both ways, remember. In many people's minds, the typewriter-oriented way of interacting with computers -- with all of its concomitant problems of multiple incompatible escape code sequence sets, control sequence tearing, terminal mode enquiry from the host end, modal character encodings, modal display, 8-bitness, 7-bitness (!), and of course all of the modem and serial line hoops to jump through -- is something that the world got away from in the 1980s and early 1990s.

The console subsystems in Windows NT, and in OS/2 1.x before it, provided simple manipulation of cursor and attributes without worrying about which escape sequence set to use or without danger of escape sequence tearing. They provided simple enquiry mechanisms for reading characters and attributes back out of the display, and for reading the cursor. There were no worries about "having bit #7 set", or accidentally dropping into "great runes mode". One could use full UCS-2 (this was pre-Unicode 1.1, remember) if one wanted to avoid worrying about code pages. The kernel didn't impose a fixed number of devices or (at least in Windows NT) a low limit on the total number of consoles. The input stream included both keyboard and mouse events in a single…

Okay, it took a little but of digging but I eventually found more about this via a link from the Wikipedia page.

* via <https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-Ps-@.1C80> (search for "CSI Pm m Character Attributes (SGR)"):

If 88- or 256-color support is compiled, the following apply:
[snip]
o The 88- and 256-color support uses subparameters described
in ISO-8613-6 for indexed color. ISO-8613-6 also mentions
direct color, using a similar scheme. xterm supports
that, too.
o xterm allows either colons (standard) or semicolons
(legacy) to separate the subparameters (but after the
first colon, colons must be used).

The indexed- and direct-color features are summarized in the
FAQ, which explains why semicolon is accepted as a
subparameter delimiter:

Can I set a color by its number?

(This links to <https://invisible-island.net/xterm/xterm.faq.html#color_by_number>.)

The `ctlseqs` document continues:

These ISO-8613-6 controls (marked in ECMA-48 5th edition as
"reserved for future standardization") are supported by xterm:

[snip example with colons ":"]

This variation on ISO-8613-6 is supported for compatibility
with KDE konsole:

[snip example with semicolons ";"]

So,…

Stories like these make me want to give modernizing vtrek another try. I'd originally played it on my cousin's 3B2 in the late 1980s after being introduced to the CP/M port of classic trek, which I played on my family's IMS 5000SX. (Oh, how I wished at the time that we'd gotten an Apple II! But that's a story for another time.) I have distinct memories of playing vtrek on my dad's VT220, dialed into my cousin's BBS over Tymenet at 1200 baud. Whereas classic trek, having been written in the era of the ASR-33, was line-oriented like a text adventure, vtrek was a full-screen interactive terminal app, like vi. You'd issue movement commands using the 3x3 block of keys of the left side of the keyboard—Q, W, E, etc. Other keys controlled the ship's scanners, shields, weapons, and warp drive. Those inputs drove the game's event loop and updated the display accordingly. It was great fun, especially for a video game starved kid like me. I was forever pestering friends and cousins to play on their Ataris or Nintendos or Apples or Tandys. I didn't get my hands on a proper gaming computer until the early 90s, when we replaced the 5000SX with a 386.

So I'm sure you can imagine my excitement when I stumbled across an archive containing XENIX ports of a bunch of Unix games, including vtrek. (Thank you, Vince!) I'm not even sure how I managed to find that. Nowadays, Google only returns two search results for vtrek, the XENIX game port archive and a munged version of the…

If you code in Java, and like TUI (console type applications), then you might enjoy Jexer: https://gitlab.com/klamonte/jexer

I started Jexer in 2013, and off-and-on it's gotten better. I think my favorite part has been crossing paths with other terminal emulator ecosystem folks over the last few years. This release brings a few prettified effects inspired by other projects that you are all hopefully quite familiar with (notcurses, chafa, and vtm):

* Translucent windows, including images under/over each other and text.

* Animated/pulsing text

* Animated gifs

* A new XtermVideoPlayer example that uses ffmpeg/JavaCV to play movies inside a text-draggable window. (No audio though.)

* New button styles: round, diamond, left/right arrows. The button ends and shadows are drawn with images so specific font support is not required.

* A _much_ faster and _much_ higher quality sixel encoder.

* Different window border styles: single, double, none, and rounded corners.

* A femme theme option.

Some screenshots are posted here: https://twitter.com/AutumnMeowMeow/status/1489228917030502407

It's on maven and Sourceforge.

<dependency>
<groupId>com.gitlab.klamonte</groupId>
<artifactId>jexer</artifactId>
<version>1.6.0</version>
</dependency>

Terminals that are known to work include:

* xterm https://invisible-island.net/xterm/ - X11 - Linux

* contour https://github.com/contour-terminal/contour - OpenGL - Linux, OS/X, Windows

* foot…

I and others have pushed changes into XTerm to improve mouse support of terminal-based applications. All terminal emulators should implement XTerm's command set, especially these:

Bracketed paste mode: allows editor to determine that text is from a mouse paste instead of typed in. This way, the editor can disable auto-indent and other things which can mess up the paste. Libvte now supports this!

Base64 selection transfer: this is a further enhancement which allows the editor to query or submit selection text to the X server. This allows editors to fully control the selection process, for example to allow the selection to extend through the edit buffer instead of just the terminal emulator's contents.

One patch of mine didn't take, but I think it's still needed: allow mouse drag events to be reported even if the coordinates extend beyond the xterm window frame. Along with this is the ability to report negative coordinates if the mouse is above or to the left of the window. Why would this be needed? Think of selecting text which is scrolled off the window. The distance between edge and the mouse controls the rate of selection scrolling in that direction.

BTW, it's fun to peruse xterm's change log. For example, you can see all the bugs and enhancements from Bram Moolenaar for VIM. http://invisible-island.net/xterm/xterm.log.html

Thomas Dickey maintains a lot of other software as well, in particular ncurses, vile and lynx: http://invisible-island.net/

TUIs are wonderful. They are easy to grasp, fast and restrict requirements, everyone involved must think about the workflow and efficient usage. Input is focused entirely on the keyboard. Linux overs some modern TUIs e.g. installer, apt-stuff or the kernel config aside from that:

https://invisible-island.net/ncurses/ // classic

https://github.com/willmcgugan/rich // blingbling

https://github.com/dankamongmen/notcurses // hacker

For the old stuff I recommend looking close at airports, savings-banks or part-dealers. When it is influenced by mainframes you will notice likely forwards/backwards is done by F7/F8. How do you depict an plane with seats in TUI? I assume an array, 80 rows and 10 columns ;)

I'm impressed how flawless elderly co-workers work with TUIs. They read the screen, think and type and the work is done. I guess the straight workflow, clean user-interface and similarities to paper forms improve usability. I guess modal dialogs, popup warnings, status icons, right click and the modern long press are not an improvement in usability. And the many tiny icons and bars in modern text processors aren't a help either.

I think we can learn a lot more from old programmers.