-- Leo's gemini proxy
-- Connecting to carcosa.net:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
So it's been around a week that I've been working mainly in the terminal, and I have to say it's been pretty good! I haven't really settled into where it's a less-intrusive and less stimulating way of computing, because I have a driving urge to tinker with it. But I think that's starting to come to an end as I get stuff working.
Last time I wrote, I was running the VT420 at 9600 baud, because it doesn't have hardware flow control (at least not that's compatible with serial ports as we know them), and software flow control is hard to use with modern Unix terminal applications because they tend to use Control-S and Control-Q as command keys. Emacs has a decent workaround (M-x enable-flow-control), but other programs don't. In my use, ncmpcpp (music player) would pop up a dialog to sort tracks periodically, and crawl (a Roguelike game) would simply quit as soon as you got a character past the selection screen.
But now I have found a solution that lets me live with software flow control, which means I can bump the terminal's nominal baud rate up to 38400! (Because the VT420 can only process 19200 bits per second, sometimes fewer when it has to deal with control sequences, flow control slows the actual rate to /around/ 19200, so 38400 baud is only marginally faster than 19200 on this terminal, not twice as fast).
That solution is: GNU Screen! I had been using tmux as my terminal multiplexer for the last several years, though I had used screen for many years before that. I think I switched because it was slightly easier to get truecolor color codes working in tmux than in screen at the time, but I stayed for a few niceties like a more interactive window list (I never used the screen-splitting features much). But tmux is a modern program, designed for use on modern terminal emulators, and screen dates back to when actual terminals (and dial-up terminal software on PCs) were still in use. It has capabilities for working with flow control. It has seen some things.
In particular, screen lets you set for the whole session, and for each window, a flow-control setting. For my purposes, the correct setting is 'on'. Screen will accept the ^S and ^Q characters from the terminal and pause or restart output in its child windows accordingly. But, and this is the other crucial part, it /does not/ pass the actual flow-control characters to the child application. If you /want/ to send commands on those keys to the program, you have to type screen's escape code (by default bound to C-a, I have it bound to C-z for Emacs friendliness) and s or q.
As a result, I now have my terminal running at a bit over 19200 baud, with absolutely zero corruption except when something sends a UTF-8 character despite my locale saying not to.
The VT420 has a built-in status line,which is below where screen output is normally displayed. It can display various terminal info that is not that useful, or it can be program controlled. This means I don't waste a line on my terminal.
Previously my process for switching was to detach screen, go into the hardware settings panel for the terminal, switch to 132 columns, run the `resize' program included with xterm, and re-attach my screen session. Now, it's `C-z W'.
Getting there was not all that easy. Fedora does not include terminfo descriptions for a very wide variety of terminals, basically because today everything is emulating an xterm emulating a vt220 with ANSI color. So I had been using the VT220 terminfo. But I wanted all the VT420-specific features I could get. So I ended up getting the terminfo source from ncurses and compiling everything. (I could have compiled just the DEC terminals section, but this was easier.) So now that I have a real VT420 terminfo setting, the resize command should work, right? Nope. Screen needs to add a couple of capabilities, but they can be added in .screenrc, so it's fine. It works now. I'm not really sure I needed to use the VT420 terminfo at all, actually.
I found a blog post where the author had gotten the alt key working partially as a Meta key in Emacs, by binding the first part of the garbage it spews out to #'ignore, and using the rest as a prefix for a number of commands that are normally on M-<key>. That worked okay, but every command had to be explicitly bound, and only a few of them were.
It turns out that screen is capable of quite flexibly translating input before it gets to your programs. I was able to tell it that all the garbage the Alt key was sending should be translated as Esc to applications. Emacs uses Esc as an alternate way of typing a Meta-modified key.
My .screenrc that enables all these things is linked below for reference, in case anyone else is setting up a VT420.
My login shell now checks if it's running on ttyUSB0, and if it is, sets up some things for use on the terminal, and tries to reconnect to a running screen session or start a new one.
I use vertico, a vertical completion framework for Emacs, which updates its suggestions as you type, and can use various types of matching. One thing I noticed is that because the screen updates as you type, it is hard for the terminal to keep up if the list of completion candidates is the default height (12 lines). Setting it to 4-6 lines makes it feel fast again, and shows me enough candidates at one time to be useful.
The keyboard remains not great, but it's okay for most things. It's making me switch between QWERTY and Colemak too much, enough that I'm thinking of just going back to QWERTY on my other keyboards, unless I discover that it starts giving me RSI again.
I've been trying out a modal editing package for Emacs called meow-edit, and it seems like it could help adjust to this not-great keyboard, and probably also be useful when using Emacs on my phone. But it has quite different keymaps for QWERTY and Colemak, and it seems like it would make it harder to switch back and forth.
-- Response ended
-- Page fetched on Sat May 4 05:13:34 2024