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.
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.