Thomas Dickey

chawan has a custom terminal module, so my knowledge about the standard X/Open curses is not that great. That said, for the actual escape sequences, XTerm's ctlseqs.ms[1] is an invaluable resource. I also took many ideas from nick black's notcurses[2], and I especially recommend his notes on "sprixels".[3] [1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html [2]: https://nick-black.com/dankwiki/index.php/Notcurses [3]: https://nick-black.com/dankwiki/index.php/Theory_and_Practice_of_Sprix…

It is kind of the same problem as for shared libraries. In the GNU universe the cleanest solution is to have multiple soversions. Transferred to jinja it would be jinja.so.1 and jinja.so.2. Maintaining fine grained symbol versioning is a pain and a massive amount of work for the package maintainer: https://invisible-island.net/ncurses/ncurses-mapsyms.html Honestly, multiple installed versions like jinja1 and jinja2 sounds best to me.

Awk is a fun, surprisingly powerful language. Even plain mawk can do a lot, but gawk has debugger support, profiling, namespaces, and even network support. (I wouldn't necessarily go out of my way to use most of those features, but it's possible!) It's honestly worth giving the mawk and gawk manual a skim just to see what all they can do. I want to read through The AWK Programming Language as well. https://invisible-island.net/mawk/manpage/mawk.html https://www.gnu.org/software/gawk/manual/gawk.html

There is a quote. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 Well, we have our cathedrals in programing, only we as as software engineers tend to be barbarians and call them "legacy code" or "obsolete systems" or "needs to be torn down and replaced with something new". Think of when people do this to actual cathedrals. I like xterm, use it daily, I think Thomas Dickey is a pretty great guy for his role in maintaining the program. https://www.invisible-island.net/xterm/xterm.html

This is a great table of control sequences, but the second author cited as maintainer from 1996 to 1999, Thomas Dickey, currently maintains a list at his invisible-island.net site. https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

I was working on terminal code recently and had a hell of a time finding anything approaching an authoritative spec or reference docs. The best I found was this: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html I'd recommend that over the wikipedia link in the article, since wikipedia seems to be missing some things.

Not to take anything away from rich/textual which are awesome, but you can produce a SVG directly if you're using xterm¹. It doesn't produce the cleanest SVG output, but it is quite workable. The dump-html function also exists in xterm, should you want to remember what XHTML looks like ;) It would be amazing if either could be used to make quick animated and automated session logs for demos or to attach to bug reports. ¹ https://invisible-island.net/xterm/manpage/xterm.html#Main-Options:SVG…

When Thomas E. Dickey [1] stops taking care of Xterm (and much else), it will be the end of an era. [1] https://invisible-island.net/

> Somehow this works even across SSH connections… The source code[1] is quite simple to read (as long as you know Bash) but basically imgcat prints a special OSC[2] sequence (some bytes that tell the terminal to do something special) to stdout followed by the image data which iTerm then handles specially because of the OSC sequence, as far as SSH knows they're just some bytes that it needs to send (no different than running normal cat on a text file). You can kind of think of this as the opposite of what bracketed paste[3] does, in bracketed paste the terminal tells the program to treat some data specially but with imgcat the program tells the terminal to treat some data specially. [1]: https://iterm2.com/utilities/imgcat [2]: https://en.wikipedia.org/wiki/ANSI_escape_code#Escape_sequences [3]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-P…

> [ESR] and Stallman were once close friends I rather doubt that. One of ESR's skills is to insinuate that he's on closer terms with people than he really is, as astutely captured by this comic: https://geekz.co.uk/lovesraymond/wp-content/ep013.jpg For a lengthy first hand report of an actual interaction between ESR and RMS, there's for instance this: https://invisible-island.net/ncurses/ncurses-license.html Does not look like former or current close friendship to me.

Wow, that is pretty fast. I played w/ doing CSV parsing taking advantage of SIMD string lookahead a while back ( https://gist.github.com/netshade/aa9e836e843c8e84b97a ) and found it to be quite fast as well, as I had assumed (perhaps wrongly) that the cost of navigating back and forth between the CPU and the GPU would erase any performance gains. I suspect ( it's been a while! ) that the SIMD approach would be faster than GPU, but tbh after working on it for a bit, then comparing it w/ mawk's (http://invisible-island.net/mawk/mawk.html) performance, mawk still beat my approach handily, and did it w/ way more functionality. Which is all to say that mawk is pretty amazing and worth checking out if you're in the market for parsing CSV fast.

I always respect the choice to prioritize readability over flashy gimmicks, and this site is a perfect example of that mentality, imo. From a quick glance I know who he is, what he does, and how to contact him. Great! I found this to be interesting. http://invisible-island.net/personal/oldprogs.html

Once you can read some C, I'd recommend reading over another bytecode interpreter, like mawk (Mike's AWK): http://invisible-island.net/mawk/ . Another good read is the TinyCC compiler (originally by Fabrice Bellard, who did QEMU among other things): http://savannah.nongnu.org/projects/tinycc . It's a small, mostly readable, fully functional C compiler.

If you are anything like me, that is, someone who loves the speed and "feel" of vim, but also enjoys the buffers of emacs. You might want to check out vile (vi like emacs). [http://invisible-island.net/vile/]

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…

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-u… (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,…

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…

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.

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…

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/

I think this is a great idea, and it looks like a lot of fun, but unfortunately, it doesn't work for me. Though I'm sure tested this on "Linux" and "MacOS X" as you said, the real problem you face is most terminal emulators are not standards compliant (assuming there are standards for particular behaviors, and often there aren't any). This means, you got it working on some terminal emulators, but it won't work on others. The most standards compliant terminal emulator is actually the original 'xterm' [1] program included as part of X. The xterm FAQ [2] and ncurses FAQ [3] have lots of useful information. Though getting your code running in xterm itself will help portability, it won't be the end of your debugging due to the fact that other terminal emulators have bugs and of course, they often do things differently. The story about the color blue [4] in the xterm FAQ should give you an idea of the kinds of problems you'll face. [1] http://invisible-island.net/xterm/xterm.html [2] http://invisible-island.net/xterm/xterm.faq.html [3] http://invisible-island.net/ncurses/ncurses.faq.html [4] http://invisible-island.net/xterm/xterm.faq.html#dont_like_blue

Start with ECMA-48 https://ecma-international.org/publications-and-standards/standards/ec… Then find DEC and XTerm extensions https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

Some vaguely related things: - VTTEST <https://invisible-island.net/vttest/vttest.html>, which tests capabilities from VT-100 to VT-520 terminals. - Markus Kuhn's UTF-8 test <https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.

s/htm/html/ I.e. <https://invisible-island.net/ncurses/tctest.html>

Does it crash the tester? https://invisible-island.net/ncurses/tctest.htm

This thing is made out of corner cases: https://www.invisible-island.net/vttest/ I am sure capturing it's output will provide endless source of amusement and despair. There are sequences from real terminal (e.g. stuff documented at vt100.net), sequences from ECMA 48 and friends (most of it likely never implemented), and de-facto behaviour of different software. Infamous examples being original windows terminal, rxvt (ugh), linux co nsole, emacs terminal. Most vexing behaviour is background fill on newline, incorrect characters in terminal reports, broken scroll region, inability to write in bottom-right position etc. This project looks fun! But it leads to endless narrow abandoned places. Hopefully you will enjoy the experience!

There's a long history of "directory editor" programs going back to (at least) 1974, which predates emacs. It's not surprising that there are many examples of convergent evolution. https://invisible-island.net/ded/dating-dired.html

Neat, this [1] looks like the project uses vttest [2] to test DEC VT terminal compatibility? [1] https://github.com/ghostty-org/ghostty/blob/main/TODO.md [2] https://invisible-island.net/vttest/

> And performance of awk is crap. [...] I had replaced all the awk scripts in python and everything is a lot faster. My experience points exactly the other way: for data-processing tasks, especially streaming ones, even Gawk is a lot faster than Python (pre-3.11), and apparently I’m not the only one[1]. If you’re not satisfied with Gawk’s performance, though, try Nawk[2] or, even better, Mawk[3]. (And stick to POSIX to ensure your code works in all of them.) [1] https://brenocon.com/blog/2009/09/dont-mawk-awk-the-fastest-and-most-e… [2] https://github.com/onetrueawk/awk [3] https://invisible-island.net/mawk/

I'm not sure what you're thinking of, but there at least 3 prominent and still-relevant awk implementations: nawk (One True Awk / AT&T awk / BWK awk): the original awk, still maintained; is used by macOS, FreeBSD, OpenBSD, and NetBSD https://github.com/onetrueawk/awk mawk (Mike's awk): the default awk on Debian https://invisible-island.net/mawk/ gawk (GNU awk): the default awk in lots of other places https://www.gnu.org/software/gawk/