it would be interesting to see what an even more minimalist and more usable terminal emulator looked like. both your work and st are constrained by having to support terminal control languages with a lousy strength to weight ratio, something oberon opted out of
Yeah, there's a ton of cruft. On one hand I find it fun to see how much of vttest I can make it through, on the other hand, supporting DECALN (DEC service test pattern - just fills the screen with capital E) is just a boxticking exercise, and while that's one of the dumbest one there are also dozens that are hardly ever used, or that are used in rare cases but doesn't really need to.
That is one area where st's "tmux copout" on scroll somewhat makes sense - it would be a reasonable option to define a clean sufficient subset that lets you run enough stuff to tell people to just run anything that breaks under tmux/screen or a separate filter.
But from what I see with terminals, there's a lot of reluctance to do this not because people believe all these codes are so important but because it seems to become a bit of a matter of pride to be a precise as possible. I admit to having succumbed to a few myself, like support for double-width and double-height characters, as well as "correct" (bright/dim rather than on/off) blink and support for the nearly unsupported rapid blink... There is also a pair of escape codes to enable and disable fraktur. This is fertile ground for procrastinating terminal developers to implement features used by one person in the 70's sometime.
At the same time I sometime catch myself hoping some of these features will be used more... A very few I'll probably add support for because I want to use them in my text editor, e.g. different coloured underlines, and squiggly underlines are both easy to do and actually useful..
I think with a cleaner set of control codes, though, you could certainly fit quite a few of those features and still reduce the line count significantly...
I have used DECALN, which is sometimes useful for testing purpose (especially in full screen, although sometimes even if it isn't).
I will want to see support for the PC character set, for EUC character sets (including EUC-TRON), TRON-8 character code, bitmap fonts (including non-Unicode fonts), Xaw-like scrolling and xterm-like selecting, ability to disable receiving (not only sending) 8-bit controls (which should be used to switch between EUC-JP and EUC-TRON, as well as other purposes), a "universal escape" sequence (recognized anywhere even in the middle of other sequences), and some security features (I have some ideas that I don't even know if it is possible on Linux or on BSD, such as checking the foreground process, and being able to discard any data the terminal emulator sent to the application program that as not yet been read yet, which can avoid a file or remote server to send answerbacks which will execute commands in the shell, if you add a cancellation code into the shell prompt, etc)
It's a one-liner to fill your screen, and the fraction of people who even know DECALN exist is so small I wouldn't be surprised if the total invocations of DECALN by terminal users in recent decades is smaller than the number of indirect invocations by terminal implementers via vttest.
It made sense as a service tool on a physical terminal, not much now. It's not that it's a problem - it's trivial to support. It's just that it is an example of one of hundreds of little features that are box-ticking exercises that would cause about a dozen people worldwide to shrug if they noticed they weren't there before they'd do the same thing a slightly different way and not think about it again.
Some of the ones you list are useful some places, but many of them don't need to be in every terminal. I want more, but smaller, options built from generic reusable components.
E.g. most of my terminal does not care what your character set is, or what type of fonts you want to use, or how your scrolling works, or if you have scroll bars, or whether there is a shell, or whether there's a program being run by a terminal vs. a program embedding the terminal, or if it's running in a window, or whether it has GUI output at all or is entirely headless. This is true for most terminals. Yet these components are rarely separated and turned into reusable pieces of code.
Most of the features you list are features I don't need, won't implement, and don't care about. But what I do care about is that with some exceptions (e.g. the Gnome VTE widget) most terminals reinvent way too much from scratch (and frankly most users of terminal widgets like VTE still reinvent way too much other stuff from scratch), put too much effort into supporting far too many features that are rarely used, instead of being able to pick a terminal that is mostly just pulling in generic components as a starting point.
The result is a massive amount of code that represents the same features written over and over and over again and sucking time out of the bits that differentiate terminals in ways useful to users.
E.g. just now I've been starting to untangle the bits in my terminal that handles setting up the PTY and marshaling IO between the shell or other program running in it and the bits that handle the output to the actual terminal. The goal is to make it as easy for casual scripts to open a terminal window and control it as it was on the Amiga, without having to spawn a separate script to "run in it".
On the Amiga you could e.g. do "somecommand >CON:x/y/w/h/Sometitle" to redirect "somecommands" output to a separate terminal window without any foreground process, with the given dimensions and title, and assorted other flags available (e.g. "/CLOSE" would give yo ua close button, "/WAIT" would keep the window open after the process that opened it went away etc.).
If you've written a terminal, then part of your terminal represents 99% of the code to provide something almost like that.
Beyond that, I'm going to rip the escape code handling out too, so code that don't want to do escape codes still can pretend they're talking to a terminal with a somewhat ncurses-y interface but with the freedom to redirect the rendering or render on top of it, or whatever, then that makes "upgrading" from a terminal UI to somewhat of a GUI far easier (the Amiga, again, had a lot of this, with apps that'd mix the same system console handler used for the terminal with few graphical flourishes; it lowered the threshold to start building more complex UI's immensely)
Then I'm going to extract out the actual rendering to the window into a separate component from the code that maintains the (text) screen buffer, so that I can write code that uses the same interface to render either to a terminal or directly to a window.
Same for e.g. font-handling - I've decided I don't care about bitmap fonts, but the actual bit of my terminal that cares about any kind of fonts is ~40 lines of code, and to most of my terminal components it doesn't matter if you output anything anywhere, but even of the remaining code actually dealing with GUI output, 3/4 doesn't care, or know, about fonts at all (managing a window, clearing, filling, scrolling take up more). Making it pluggable so someone could plug in either a client side bitmap font renderer or code to use the old X11 text drawing calls is trivial.
Because with all of these things broken out into components it doesn't matter much if my terminal doesn't support your feature set, if "writing another terminal" doesn't mean writing the 95% of the code that implements shared functionality over and over again.
You could write literally half a dozen of custom tiny terminals like that before even approaching the line count of xterm's mouse button handling code alone.
That is good, to have separate components of the codes, that can then be reused. Do you have terminal emulator codes with such things? Then, we can see, and it can easily be modified.
i've been thinking that maybe nested tables would be better than character cells, for example, accommodating proportional fonts and multiple sizes much better
Everyone has... I'm not sure it's a big loss, but I found it funny to "fix" and the fun of tweaking tiny things like that lies at the core of a whole lot of terminal bikeshedding...
> i've been thinking that maybe nested tables would be better than character cells, for example, accommodating proportional fonts and multiple sizes much better
A lot of simplicity could easily go away if it's not done well, but I like the idea. I want to eventually support some limited "upgrades" in that direction, but will take some cleanup efforts before that'll be priority.
it would be interesting to see what an even more minimalist and more usable terminal emulator looked like. both your work and st are constrained by having to support terminal control languages with a lousy strength to weight ratio, something oberon opted out of