> There is no way to see if the user pressed only Control or Shift, because from a terminal’s perspective all they do is modify a bit for the typed character.
Modern terminal emulators can do this using the xterm modifyOtherKeys protocol, which sends escape sequences for such combinations.
I don't know about other terminal emulators but with XTerm you can modify its translation table and have any keys combo sending custom things.
It's all very tricky and quite an arcane art but it's possible to get, for example, the "Hyper" modifier when Emacs is ran inside an XTerm (that is: in "-nw" / no-window mode).
Disagree. As with the graphics discussion the other day, Kitty seems to have a NIH problem. At best, it's unnecessary extra work for other projects to support another flavour; at worst, it leads to fragmentation.
Meta: I'm not among the downvoters; on the contrary I aim to upvote any on-topic reply (although I don't always get back to a thread, and anyway I suspect all my votes are shadow-ignored).
I get why Kovid (the author of Kitty) wants to invent new protocols that improve on the existing ones (Kitty’s image protocol is quite a bit more efficient than Sixels, for example), I just don’t understand why he won’t implement both the old and the new. Supporting both Sixels and his own image protocol at the same time would be almost trivial. Of course only one keyboard protocol can be active at a time, but surely the user should be able to choose between them so that they can use software which already supports XTerm’s escape sequences.
You seem to be overlooking the fact the modifyOtherKeys is 1) not well designed. 2) And does not solve the problem comprehensively.
1a) try to figure out what the escape code for the play/pause key is
1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes
1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not.
1d) it does not support any modifiers beyond the basic 4
1e) It has no support for lock keys num lock/caps lock
1f) It has no support for alternate keyboard layouts
1g) it has no support for shifted keys
2) How does one represent release events in modifyOtherKeys?
xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.
Escape is traditionally distinguished from an escape code by a timeout: if no more characters arrive within some small number of milliseconds, then it was the user pressing escape and not the start of an escape sequence. No new solution to that “problem” is really necessary.
Likewise, programs don’t really need to know if the terminal supports an extended set of key combinations, because they can just react to them if they arrive. If they don’t arrive, then either the terminal doesn’t support that feature or the user didn’t type that key combination; either way the program needs to do nothing.
As for modifiers, good look finding a keyboard that supports more than the basic four. No need for xterm to go out on a limb and support something you can’t use anyway.
And who cares about num lock and caps lock? I’ve never seen any program care what state they were in. Well, GDM does warn you if capslock is on during a password prompt, but that is very niche.
Terminals have never operated on scan codes, so keyboard layouts are irrelevant. The application doesn’t really care what button you pressed to get a Q, just that you typed a Q.
Likewise there has never been support for key release events on terminals. I suppose it’s useful for games, but in most other situations the user will have autorepeat configured and that will handle it.
Why should xterm go out on a limb and invent a scheme that tries to cover every possible future need, even needs that are not in evidence? Better to implement something simpler that just covers what is actually needed. It can always be extended later.
So now everyone on the planet has to suffer from slow response to esc keys because xterm is too lazy to fix it properly. And its not a "few milliseconds". Terminal bytes can come over networks with arbitrary delays, so you either get inaccurate key presses causing potential data corruption/loss or insufferably long delays. It is this kind of lazy thinking that has bedeviled this poor ecosystem.
Yes programs need to know about an extended set of key combinations, because lots of programs just spill escape codes they dont understand to the screen. So you cannot produce such codes arbitrarily, only when a program indicates it wants them. And as is usual with xterm, it didnt bother to think this through. It has a facility for requesting these extended keys, but that facility may or may not work. And there is no way to detect if it has short of waiting for those keys. So if a program wants to say, present a different interface in terminals that support extended keys, it cant do so, because it has no way to know if the terminal does support it.
I dont need a keyboard that supports physical keys. I can repurpose unused physical keys as modifiers.
Its nice you dont care about num lock and caps lock. Its not so nice that you are foisting your lack of care on the rest of us.
Let me paraphrase what you said about keyboard layouts. "Something was not done previously and therefore it should never be done". Support for layouts means pressing ctrl+letter can work even on a cyrillic keyboard, but of course, terminals have never done that, and everyone speaks english anyway. So no one cares.
You suppose its useful for games? Try making a game that uses keys for real time control without release events. Autorepeat my ass. But ofcourse, no one cares. Are you in the habit of assuming that because you dont care about something, everyone else also must not care about it.
xterm absolutely shouldn't. it would make a pigs breakfast of it. I am very happy it didn't. What you should do is stop advocating for a broken, half assed hack.
terminal is useless garbage. i literally have PTSD from using the mouse scroll wheel while reading a man page because for the longest time there was some obscure misconfiguration or bug in my terminal or something above it: you would scroll and some random pieces of text here and there would not render. whenever i read a man page on that system, i would realize i missed an important part later on because the bug where that piece of text doesn't render was present. this isn't because graphics programming is hard, it's because the terminal is obscure error prone crap that nobody not even the most die hard hackers want to learn to configure properly (the most die hard only learn enough terminal stuff to look smarter than their peers, and stop at that)
the idea of your program not doing graphics, but instead invoking and interacting with a simulated model of a teletype (a device nobody born after 1990 even knows what is) so then the graphics stack can render its behavior to screen is completely asinine, like on the "anyone who uses this in their work should be fired" level.
i could never decide what's stupider, this or the C language. both were obsolete 30 years ago. yet diehard patriotic nostalgia tripping nerds who have no idea how software engineering works but just want to learn complicated things to look cool fought tooth and nail to keep this crap alive for decades. whenever someone says "the UN*X way", they really are saying, "I designed something modularily, you could have never thought of that", but what it really means are all these insane nonsense ideas that don't even begin to make sense, like:
-a filesystem centric security model that doesn't even begin to address real world use cases
-C
-ad hoc encodings that never mattered like octal, everything being a int<my machine word size>
-*sh
-perl, tcl
-terminal emulators
-DNS
-all these shitty little tools that compose horribly, like sed, where you have to pass --sandbox to make up for the fact that it indeed composes horribly
-web and email, which are thoroughly embedded in UN\*X influence, and ergo, suck big time
-X.509
this is why open source sucks and is barely a competitor to proprietary garbage running in your IoT device. in fact, every single vulnerability in them springs from these bad ideas.
It's not about "open source", it's about compatibility. Changing the terminal text protocol is akin to changing a public API and would break programs. Actually, it's worse than changing a public API as you get no error and either nothing happens or the wrong thing happens and there is no good way to signal versioning (you can do some communication in "raw mode", but in the default buffered/cooked mode you can't really).
Almost all your gripes are about compatibility, really.
i said open source sucks because the community is on UN*X mentality.
why does the console (it should be called console, as terminal refers to a setup that was obsolete 30 years ago) not have a proper input line? why does pasting a newline make it run? i should be able to type a command and edit it in a line that is a separate UI element from the text output. there is no compatibility argument here. only 0.001% of programs actually need to do anything other than be run and output text (and just text, not escape characters that do funny stuff). there's no dilemma that you love to imagine where changing it to work this way would cause massive incompatibility problems. we could even just make a new console called dumbtextconsole that works this way
viewing some logs from the shell is annoying as hell because the input goes into the program and once the program exits the shell runs whatever you typed. this is obviously a bad UI design. you will always have this stupid invisible buffer that you have to keep track of in your head the number of times you accidentally typed a letter there. if you ssh or tmux in, then you are more likely to enter bogus characters by accident when mistyping a command to ssh/tmux. the argument that its needed for compatibility is still moot if you only want a console for running commands. you dont need those interactive commands either. those are the most bogus hacky scripts that serve no purpose. i dont need a terminal to edit files either, that can be done with a proper GUI that runs outside the console.
it's also a security vulnerability the way shell input works. since you might paste something with a newline on the end and it will automatically execute. the idea that you should be responsible for what's in your clipboard is just bogus. you are resorting to some ad-hoc philosophy to argue this. if there was simple a proper input line where you pressed enter to run it, this wouldn't be a concern.
that one python shell.. Dreampy does this, no problem. the insane user who thinks it's a thing for some function to hijack random parts of the terminal[1] has his program break, and the rest of stuff just continues to work
this post also answers the "there are no alternatives" hackjobs in this comment chain. clearly there are alternatives, i just stated some, and once you follow this line of thought it actually leads to an entirely different OS (duh, why did i even have to state this, oh yeah, because you're disingenuous hackjobs). the fact that these people have the audacity to claim that UN*X, which is a absolutely highly specific way of designing things, that would never happen in isolation, is the only way to design an OS, proves how big of an issue this is in the software industry.
1. the insanity here being obviously that once you change random attributes about the global shared state, you have to assume other programs don't get the same idea as you and do stuff in conflicting ways
Yea, the default in Bash changed at some point too, but in either case your terminal emulator has to support bracketed paste mode. (Basically it puts an escape sequence before and after the pasted content.)
wait, you're arguing that devices should emulate a typewriter that hasn't existed for 30 years because it somehow makes them easier to debug, while this thread is about how they cause obscure problems that require you to understand escape codes to fix for things as basic as key mapping? perl does not make anything easier to debug... everytime i read perl i have to learn the subset this particular user is using, and everything in perl is a backdoor like 10x worse than bash
If you say that you never debugged bash with bash -x or never read 'perldoc perlintro', because perl it's like an improved awk, sh and bash made into a very simplified C-like language.
Unfortunately, the IT industry seems to have at some point decided that UNIX and C are somehow fundamental to computing, and the only way forward is to build more and more layers of abstraction on top of it.
The most depressing thing is that even "indie" OSes buy into this garbage (Serenity, Redox, ...). Yes, you get tons of (crappy) portable software that now runs on your platform for free, but at the cost of being stuck with a lowest-common-denominator API.
Do you mean macOS, Windows or something else? I’m also not sure if ggp’s concern is a terminal per se (as in a rectangular box of monospace text) or its mechanics, so which software or behavior are we talking about?
It’s a sincere question, because I also believe that user interfaces could be better and there is a room for discussion, but ggp only enumerated observable downsides without explaining how to transform them without losing functionality. Maybe I’m thinking in-the-box, but how could I e.g. control process groups if a terminal was just a canvas and some app wouldn’t support C-z? Or if a process group is also “UNIX”, then what’s the alternative to, well, a group of processes? The initial comment brings many questions without mentioning anything that could at least direct the line of thought.
Unix and core utilities are easy to implement and run everywhere. NetBSD runs on a toaster. A Z-Machine interpreter runs text games under 2MB under Musl based OpenWRT, a C compiler like TinyCC and DFrotz. A tiny Perl edition with that, under 16MB. I ran Linux (yes, OpenWRT) under an AMRV5 machine with 32MB of RAM, 48 with the compressed ZRAM. I could script things local and remotely in these constrained specs.
For tiny games (and applications) in these machines, SDL ran everywhere, so most 320x240 and 640x480 ran on these embedded machines. Uberportable, fasts an dedicated UIs existed such as the GP2X menu. Thank libre software and Unix like OS and libraries for that. SDL and framebuffer based
software exists, such as PDF readers and video players. Thus, you could design an electronic billboard for ads in the streets/subway with very little and a ridiculous power cost, being the big screen the most costly component here.
Back in the day, for SCUMMVM (Lucas Arts adventure games) they used tons of Unix utilities to generate the engine and data handling, they saved lots of hours on engineering. The same happens today. These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.
UN*X does not have anything that makes it inherently performant in contrast to a sanely designed OS with one language instead of 10 that all do the same thing, a terminal emulator which is by design non performant, and a bunch of text formats that are also non performant and have bad semantics
> These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.
no, it really can't. if you are string flinging on such a high level, your code is broken to hell. the reason perl awk bash sed suck so much is that they are intrinsically insecure the moment any input anywhere can be controlled by an adversary (and just wonky and gets in the user's way without even talking about security). working around that requires extreme levels of discipline that go far beyond programming in a real general purpose programming language (java, C#, ML, Pascla, Ada, etc). the moment you are able to write a secure *sh program, you are spending 3x as much time per line of code than in a real language.
Unix is designed with C. C it's the Unix API, among some additions, like Posix. Advanced Programming in the Unix environment is your guide.
>Perl/awk/sed suck so much...
Perl replaces awk, sed and sh and it's far better than python for system scripting. Python with whitespaces it's a clusterfuck.
>Secure sh program.
Perl has pledge(4) and unveil(4) support under OpenBSD from base. Far better than Java and C#. And I consider OpenBSD the correct BSD descendant following the best philosophies from Unix, even if I use Hyperbola GNU/Linux as a daily basis because of the freedom of sharing.
And OFC a good bunch of OpenBSD tools are installed here, such as Oksh and sndio, doing proper audio mixing in userspace (and loopback monitoring, cool for WebSDR's and radio tools). Easy peasy. Try that with Windows.
This is the one time I envy people who use the US layout :-D
Ctrl-[ is impossible to type on, say, a German layout, as the [ character is hidden behind AltGr + 8, where AltGr is the right Alt key, which is itself (for most terminals/systems) just the combination of Ctrl+(left)Alt. So you'd basically have to type Ctrl+(Ctrl+Alt)+8 which is not possible....
I remember reading something, or maybe it was a talk on some conference, by someone who had some deep knowledge of the terminal layer. He explained some ways for alternatives to, say, ctrl+i, because something about the way the control characters only use 5 bits and if you type ctrl + a key that has the same lower 5 bits as "i", that also works like ctrl-i or something. I've been trying to find that video (or web page) again but I couldn't. But I think back then I found a replacement for ctrl+[ but I have long since forgotten it ...
For most terminal emulators (and not gVim or editors with Vim bindings), you can also use Alt+[first key you want to type in normal mode]. e.g. Alt+J to enter normal mode and go down one line. Or Alt+Space to enter normal mode and go forward one space (which usually has the apparent effect of entering normal mode without shifting the cursor backwards, which is pretty intuitive).
I never understood the "swap ctrl and capslock" thing. Why would you want to move ctrl up to capslock? IIRC only the very first IBM PC keyboards (Model F) had the ctrl key up there. And I get it, muscle memory can be annoying (that's the main reason I stick to the DE layout), but I don't believe that everyone who suggests swapping ctrl and capslock is old enough to have used a model F keyboard in his youth?
And I understand that accidentally hitting capslock can also be annoying when typing, but that happens so rarely (for me) that it's not an issue, and one could always just disable the capslock key in that case.
Less strain in your fingers. The physical Caps Lock key it's more reachable than the Ctrl one. My muscle memory got "rewired" in few weeks after using Caps Lock as Ctrl.
I tried swapping CAPS and Ctrl, and I understand the appeal, but I guess I just like pressing Ctrl in the default row - sometimes swapped with superkey - with my palm.
People who used vi/vim may also know this one as a way to get out of insert mode that is somewhat easier to reach. Nowadays I remap the TAB key to send ESC.
I wonder if that remapping also allows you to use ctrl-i to get out of insert mode. If that's the case, you can switch between the two by pressing i and ctrl-i.
Well, the article says: "There is no way to distinguish between the Tab key and Control+i. It’s not just ‘the same’ as Tab, Control+i is Tab." So you'd be mapping Tab to Escape to get out of insert mode.
If you :set autoindent you'll never need to indent using the tab key. Indentation happens automatically as you write code.
In the very rare cases where you need to change the indentation of a line, there's == or, if that doesn't work, you can indent a line forth and back with >> and << .
> Image 3, Ken Thompson working on the PDP-11 using a Teletype (model 33?). What always struck be about this image is the atrocious ergonomics of … everything. The keyboard, the chair, everything about the posture: it’s all terrible. Inventing Unix almost seems easy compared to dealing with that!
I've seen this photo a hundred times and never thought about that. I wonder when ergonomics started being a thing when designing computer workplaces.
Remember that the Teletypes were old school telco, mostly output devices, repurposed for computers. They were constructed first to be extremely durable, and then somewhere way down the list of requirements, easy on the users. The typical use case wasn't to pound on them all day long (tho some did), and you can tell.
Seem to recall that ergonomics really took off in the 80s and 90s, as people started suing for things like RSI which made companies start to care. I remember that was when everyone seemed to be swapping out for adjustable chairs and bolting keyboard trays on desks and having everyone take ergo training.
They were constructed first to be extremely durable, and then somewhere way down the list of requirements, easy on the users.
I watched this documentary, about a huge computer, just massive, huge, and a guy called Forbin. It showed governement spending out of control, and the ensuing disaster, although I was a bit high at the time, and the plot eluded me.
Anyhow, the terminals seemed much nicer than you describe, so maybe it was down to the employer?
"Colossus: The Forbin Project"? Not a documentary though.
Military computer joins up with its Soviet counterpart and takes over the world. There may have been some teletypes, but the more memorable output device was the big scrolling line of text.
RESTORE COMMUNICATION -- FROM COLOSSUS -- TO GUARDIAN -- OR ACTION WILL BE TAKEN
Brian, on the other hand, has an excellent, powerful posture: https://www.youtube.com/watch?v=tc4ROCJYbm0 (see from 4'10). Feet on desk, keyboard on lap, reclined seat, talking about unix filters.
If anything, speaking as someone who has RSI and collects typewriters, you've been spared despite them. The traditional typewriter keyboard arrangement with rows increasing in vertical height as they move away from you is precisely the opposite of what you want, ergonomically.
It's strange to me that so many computer keyboards still have fold-out tabs at the back to emulate this. I even saw an old PS/2 keyboard with terraced rows just like a typewriter! But habit is a powerful thing. Pardon the tangent, but we're using an 1870s design whose main constraints were making room for key levers to travel up and down (which is also why we have staggered keys instead of an ortholinear grid). The funny thing is that there were decades more of alternative typewriter keyboard designs (look up the Hammond 1 for an example), but the first commercially successful typewriter, the Sholes and Glidden, is the one that won out in the end.
I wonder when ergonomics started being a thing when designing computer workplaces.
IME, it was the early to mid 90's. Suddenly there were consultants for everything, and office/ergonomics consultants started popping up.
I suspect it's related to the shift to the widespread use of computers in the office. Carpal tunnel syndrome went from obscure to an "everyone knows someone with it" kind of thing. I knew someone who eventually had to wear big arm-length metal braces while using a VT-52.
The bean counters figured out that if they made small-money adjustments to their workplaces, they could save big money on health insurance premiums.
DEL's an exception because it had to be all ones. The idea is you can turn any character into a delete character by punching out the rest of the row on a punchcard. Were it any other character, you'd potentially have holes you needed to un-punch.
For my Rust book I've just been diving into the old BSD 4.4 source code for cat which converts control characters into printable ASCII with the -v flag and it handles DEL as a special case: putchar(ch == '\177' ? '?' : ch | 0100). But if you XOR the character with 0100 (64) it always clears the 7th bit, which results in '?' for DEL. Interestingly, peeking at the GNU coreutils code it also handles DEL as a special case and just prints "^?".
But that still doesn't result in a control character. In my terminal (testing with cat -v) I just get a beep (and it's not a BEL character!). Because the 7th bit of 35 ('#') is already 0 there's nothing to convert it into.
That explains the convention of using repeated ^H in a post to show one deleting a word (typically what they really meant) and replacing it with something more acceptable. Occasionally, I saw people use a single ^W instead for that purpose.
^H deletes a single character, while ^W deletes a whole word in many different programs, including those that use GNU readline (e.g. bash). Similarly, ^U commonly deletes the whole line, or from the cursor to the beginning of the line. ^U is particularly useful when you think you might have mistyped a password and there are no indicators about how many characters you've typed (e.g. ssh or sudo).
On Usenet, it was customary to use ^L (form feed) to hide spoilers, because text-mode readers would then blank the rest of the screen until you paged past the form feed.
Bob Bemer, consider the "Father of ASCII", died in 2004 and his website has gone offline. The Wayback Machine has archives. It looks like the last one that was his website (before the current squatter) was: https://web.archive.org/web/20180511201723/http://bobbemer.c...
Ascii is the reason why we have teletype control signals in our text files; I wouldn't call it particularly good solution for what it ended up being used as. Some sort of cleaner separation of control signals and data payload would imho been better
When ASCII was designed teletype like applications were still prevalent. Lots of printing instead of outputting to displays.
Nowadays, it's of course a bit wasteful that of the first 32 characters of the most used character set only about one third is still being used. And it's pretty sad that the separators control characters are not used. We could have a much better CSV with them instead of the error prone CSV we have know.
That’s only a complaint for people who use CSV. If you use the ascii characters for record, file, unit, and group there are no problems with data payload
> If you use the ascii characters for record, file, unit, and group there are no problems with data payload
Unless your data happens to contain record, file, unit, group separators... Which is kinda the whole problem; ASCII does not have any proper separation/layering between the data and control characters.
The TAB character is not any different from the separator control characters.
It is as non human readable as the other ones. It's just that it got more support historically.
If e.g. Microsoft had used the separator control characters for CSV you can bet those control characters would have even better support than TAB does today.
Common Lisp was designed by a committee, and is widely regarded as an excellent language (or at least an excellent Lisp). It even has principles that it sticks to throughout. For example, it is deliberately designed to be a multi–paradigm language, allowing the user to write programs in functional, imperative, or object–oriented styles without forcing one or the other.
DEL derives from earlier teletypewriter codes, and is based on the use of paper tape. All bits set means all holes punched, so it's the only code that can eliminate any other code.
On punchcards having it as the highest character (with all holes punched) is the only way you can reliably do "delete" or "ignore" outside of having a special dedicated hole for it.
The first element of an array is usually indexed by 0 (usually here means in most modern programming languages). The second element is usually indexed by 1 etc. So the eight bit in a byte is indexed by 7, but that doesn't suddenly make it the 7th bit.
These titles are actually forced by websites like Hacker News, as a dry and fully-descriptive title doesn't get clicked--nor should it, as it has no reason to make the reader care--and yet Hacker News has this unfortunate rule where it usually attempts to disallow what it calls "editorializing" and so the way users coming from other sites often try to submit things--using pull quotes to direct the reader to specific informative bits that make them more likely to read the article--get their title reverted (even often awkwardly after the post has received a ton of upvotes and the discussion has surrounded the submitted "title", which I feel should be a signal that--at least in some examples--the title wasn't harmful, and was merely "I wanted to link to one paragraph and not a full article", which otherwise requires "blogspam" where you write an article that summarizes the other article and calls out the paragraph, which is also disallowed for good reason, and so this website also awkwardly encourages casual plagiarism).
The result is that, rather than articles getting contextually-dependent links that are customized for the community and the time (and which lead to particular discussions), you as the author have to try to come up with a single title that somehow manages to simultaneously be a reasonable title but also serves as its own pull quote (which also effectively prevents long content or manuals from getting linked at all)... it is utter madness, and that the moderators here don't seem to understand this dynamic (even in a "we realize this is bad but we are stuck with it for various reasons--which may include some that are trade offs--but are interested in looking into alternative options" way... dang, as one example, seriously seems to only defend this behavior as good, citing some form of author control despite failing to show that this isn't a problem for authors) is the main reason I wish Hacker News didn't have a from-network monopoly on this community :(.
It was intended to be "a dry and fully-descriptive title" though.
Originally I wrote "why does ^I insert tab?" because it's a common question that kept coming up on the vi.stackexchange.com site. I figured a canonical slightly more in-depth answer would be useful.
To properly explain things a table is useful; but you can't really add that well on Stack Exchange sites because there's very limited formatting, so I had to create a site. I also never found ascii(1) convenient and most search results for "ascii table" are crap, so it became a "two flies with one stone" kind of thing.
Then I couldn't decide which title to use, so I added both. That's the only reason the page has the title that it has: the page has two purposes, so it has two titles. It wasn't intended to be cute or to grab anyone's attention. I'm surprised it was even submitted (and upvoted) here.
The earliest title with this format that I know of is "Is Sex Necessary? Or, Why You Feel the Way You Do" by James Thurber and EB White from 1929. But, that book was a parody so presumably copied the form of its title from contemporary books.
The most famous book title I know with that format is Frankenstein, or The Modern Prometheus. It's so old a style that I find it funmy that it could be seen as a fad.
Modern terminal emulators can do this using the xterm modifyOtherKeys protocol, which sends escape sequences for such combinations.