It seems backwards to sprinkle keys like ‘tab’ through the control range, and push ctrl-i into some special encoding.
One interesting link goes to libtermkey, which says the following:
Note: This project is now DEAD; end-of-life. There will likely be no further releases.
All of the code will be migrated into libtickit instead. libtermkey should not be used for new programs; use libtickit.
Sounds like it got superseded by a library that handles all sorts of terminal things (which then says it uses libtermkey for input).
I have forked it with some changes I needed for my TUI projects https://github.com/pjanouch/termo and fixed a few things I ran into as well.
It is about as messy as the original but in general it works okay.
The input part of ncurses has an awful API and is also severely broken, so there was no other way. Well, there’s S-Lang but it has a problematic license, and various popular applications have their own custom handling.
CADT in action?
I would really like to know what Thomas Dickey (maintainer of xterm, ncurses, vttest and, oddly, lynx) thinks about these proposals. Although not many people use xterm as their main terminal emulator these days, and lots of apps avoid ncurses or use some simplified wrapper on top of it, he’s probably spent more time studying terminals and dealing with compatibility issues between hastily-written programs and hastily-written terminal emulators than anybody else on the planet.
I mean, this all sounds pretty reasonable to me, but I wonder if it contradicts some edict of ECMA-48, or there’s some software that totally fails to understand the F1-F4 codes with modifiers attached.
[Comment removed by author]
It doesn’t? Handling SIGWINCH is probably one of the easiest things to get right.
Doesn’t it depend on which terminal is used though? Rxvt for instance, never had an issue. And for things that require a certain size like serial consoles (e.g. 80x24) tmux can be used.
Explain what doesn’t work?
I didn’t downvote your comment, but here, I’ll start, so we can break the chain.
Your comment said “resizing doesn’t work well in terminals”, which can be read as “for all X where X is a terminal, resizing doesn’t work.”
However, there are several valid counterexamples, of the form “rxvt is a terminal, and resizing works in rxvt”. Also: resizing the default terminal in OSX appears to work in my experience.
So it’s possible that you’re right either for some definition of ‘resizing’, which people would be interested and excited to know, or maybe it’s possible that your statement was too broad, but that you might have special insight into some X or type class of X that exhibits unusual behavior; and that would be an interesting fact to know; and engineers love facts.
So when you’re not responsive to the question raised in the previous paragraph, people might think you’re just trolling and/or are being obtuse, both of which seem likely to draw downvotes. Does that help?
Well, if you really need an explanation, I would say people think that resizing does work. Repeated assertions to the contrary, without supporting evidence, aren’t illuminating.
Do you have a specific problem in mind? Resizing works fine for me using rxvt-unicode and tmux. Occasionally some program won’t resize correctly, but that’s the program’s fault.
Or just put them to bed. There’s a growing trend to treat these little text-oriented channels as some kind of retro experience, a kind of “disco terminal” that artistically capture something from old screenshots of 3270’s and BBS’s, but really does not do justice to how awful those systems made interoperability.
“Interactive” programs are bad, and when disco was popular we had to use keyboard stuffers and expect to workaround the unwanted flamboyancy of software developers if we (lowly sysadmin) had to get any work done. I have no desire to return to this, and so if I can’t get working terminals I would rather terminals stay broken just so things don’t get any worse.
Nevertheless, I fear this trend will continue, and I would recommend instead of “yet another ad hoc xterm extension”, considerably more care: I use the Mac-UK layout, so # is pressing ⌥3 which is sadly exercised quite often in programming. Trying to take over my modifier keys like you’re suggesting is only going to make using my using your software harder so consider specific commands you wish had a high-priority key to access, then then make recommendations for the escape sequence and intention so that we can discuss those commands, and the keys used to generate them (in different layouts) separately.
IMHO, don’t shoehorn a GUI into a vt220. The Unix command line is great, as are GUIs, but putting that GUI into the limits of your terminal are silly.
I sort of like TUis, for the main reason that I enjoy a mainframe-type work style, where I run a lot of my applications as persistent, usually-open applications inside tmux on a server somewhere, and just attach to them now and then from my local device. This is possible with real GUIs too, but compared to a TUI over SSH, using VNC ends up feeling much more laggy (perhaps because applications are built differently, expecting low-latency interaction) and is more of a bandwidth hog. And most of the other solutions are either a pain to get working, not cross-platform, or both (X-over-ssh, NX, RDP, etc.).