3 ms·

Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of

Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either. Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit. This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be. Software business models have absolutely nothing to do with why you can't have key up events in ttys. EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).

ironmagma 8y ago
There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.
- cryptonector 8y ago
  There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.
  - ironmagma 8y ago
    It is a big deal, but honestly as somewhat of a visionary I would rather see an open source platform that decided to cut ties with such a legacy system that causes short term pains in favor of longer term advantages. That transition has to happen at some point for a platform to become more versatile, and if it's put off indefinitely, that just resigns itself to being not the best possible platform it can be.
    - csande17 8y ago
      The thing you have to keep in mind is that once you start cutting ties with legacy systems, breaking changes will keep happening. Today, it's key-up events. Tomorrow, it'll be something else. And eventually, the new and shiny subsystem you introduced today will be considered legacy code by someone else, and it too will be tossed out and replaced. In the end, you'll be choosing between a platform that requires you update every piece of software you maintain every six months and a platform that doesn't. And while the former might seem better from a pure-ideals perspective, the latter is vastly preferable for actual usage. (That's why so many people use Windows, and it's why I now run Linux on my MacBook.)
      - ironmagma 8y ago
        That's an interesting perspective, but it seems unlikely that that is the main or even an important advantage Linux has over Windows. After all, you can't really run old Linux binaries on a new Linux system without strong determination and a lot of time. There are many others, including its (essentially) fully open source nature definitely being up there.
- csande17 8y ago
  > Sure, you can fix it, you just might have to [...] say goodbye to running all the programs currently out there. One problem with doing this is that the only reason anyone uses Linux is to run programs that are currently out there. If Linux started to make breaking changes like this, people would switch to some other operating system that didn't break their software. Sure, lots of people use macOS, and macOS breaks a bunch of APIs every year. But macOS users also buy expensive recurring subscriptions for every app they use, so Mac software companies can afford to employ developers to clean up after Apple every year. Linux doesn't have that; a lot of Linux software is either unmaintained or maintained by volunteer developers in their spare time.
ordu 8y ago
> No, no one can fix this. I don't know about this mythical "one", but I can. I just see no reason to fix it. It is not so hard to make a patch for a /usr/src/linux/drivers/tty/vt.c to make it accept one more esc-seqeuence which would switch terminal into special state, when terminal will send keyup and keydown escape sequences instead of raw-keys for each keypress. A week of tinkering with vt.c and viola, terminal can send keyup and keydown. (Plus maybe one more week to decide how to encode keyups and keydown the best, so ideally terminal would be useable even after wrong esc-sequence sent to it in the wrong time). The right question is: and what? Why might I wish to do this? I might invent some application for this new feature, but I'm pretty sure I couldn't invent something useful what can't be done without keyup event.
- derefr 8y ago
  That doesn't fix it, on its own. You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. Can an ncurses program now detect a keyup through this? Can a Docker PTY? Can the JVM? Etc. In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.
  - cryptonector 8y ago
    Exactly. There's more to it. And yes, it can be done, literally, and I'm sure several participants in this thread could do it. But there's practically no demand, so it won't get done.
  - ordu 8y ago
    > You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.
zamalek 8y ago
> No, no one can fix this. The nice thing about escape sequences is that they are ignored if not understood. > Microsoft can't fix this either (in Windows Because it's not an issue in Windows? The Windows console, as primitive as it is, supports monitoring the status of the keyboard (which can be used to infer key up events).
- cryptonector 8y ago
  MSFT is adding a pty driver and support for Unix-style applications.
- bboreham 8y ago
  > The nice thing about escape sequences is that they are ignored if not understood. This is not what I find when I press my arrow keys in a container terminal set up with no TERM variable. I get funky characters spewed across the input line.
mikeash 8y ago
There are terminal emulators that can display images, make clickable hyperlinks, track the mouse cursor, and dynamically update the title bar with custom text. None of that was possible in the 70s. To say that this is impossible is to ignore how terminal emulators have actually evolved over the years.
- darkpuma 8y ago
  A typical modern terminal emulator running under X will export WINDOWID that is the X id of the terminal emulator window. With this you could detect key-up events. I've never seen anybody do this though. The only uses of this I've ever seen are detecting when the terminal emulator goes out of focus and drawing images on top of the terminal emulator. I've not done a detailed survey, but I believe this used to be the most common way of displaying images "in" terminal emulators before terminal emulators started supporting inline images encoded as escape sequences (e.g. iterm2) The problem with having the terminal emulator implement it is getting the terminal emulator to know when to insert these new key-up escape codes into the psuedo-terminal. The terminal emulator shouldn't send them to the psuedo-terminal when it's in raw mode, because every existing program that runs in raw mode won't know what to do with them. And inserting them into a cooked mode pty simply makes no sense. So it becomes clear that the terminal needs a "rawer than raw" (still bleeding?) mode, and some way for the program requesting bleeding mode to communicate that desire to the terminal emulator. Right now, that's not how the whole stack works. A program tells the psuedo-terminal (kernel) whether it wants raw or cooked mode, that's not something that terminal emulator is involved in. You could potentially have a terminal emulator that accepts a proprietary "toggle bleeding mode" escape sequence, at which point the terminal emulator starts inserting key up escape codes into the pseudo-terminal which it assumes has been placed into raw mode appropriately. There's not really any technical reason this couldn't be done, but there's a strong "nobody needs this" social reason for why it hasn't been done. Sure, if you want responsive controls while play aalib quake in your terminal emulator across ssh, you'd want this. But who does that as anything other than a gimmick?
- cryptonector 8y ago
  Making links clickable requires no changes to the protocols spoken -- the emulator merely recognizes URIs. I know about mouse support. Updating title bars actually goes back a long time. Displaying images... I've never seen -- can you tell me about that? I've actually outlined in this thread how to implement key up events, if that really was desired, in ttys, but I argue there's no real demand, and it won't happen. And it is impossible now in the sense that... the functionality does not exist.
gnachman 8y ago
> No, no one can fix this It's been solved twice, but I'd like to get that down to just once :) https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling https://sw.kovidgoyal.net/kitty/protocol-extensions.html#key... https://gitlab.com/gnachman/iterm2/issues/7440 https://gitlab.com/gnachman/iterm2/issues/7440

ironmagma 8y ago

There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.

cryptonector 8y ago
There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.
- ironmagma 8y ago
  It is a big deal, but honestly as somewhat of a visionary I would rather see an open source platform that decided to cut ties with such a legacy system that causes short term pains in favor of longer term advantages. That transition has to happen at some point for a platform to become more versatile, and if it's put off indefinitely, that just resigns itself to being not the best possible platform it can be.
  - csande17 8y ago
    The thing you have to keep in mind is that once you start cutting ties with legacy systems, breaking changes will keep happening. Today, it's key-up events. Tomorrow, it'll be something else. And eventually, the new and shiny subsystem you introduced today will be considered legacy code by someone else, and it too will be tossed out and replaced. In the end, you'll be choosing between a platform that requires you update every piece of software you maintain every six months and a platform that doesn't. And while the former might seem better from a pure-ideals perspective, the latter is vastly preferable for actual usage. (That's why so many people use Windows, and it's why I now run Linux on my MacBook.)
    - ironmagma 8y ago
      That's an interesting perspective, but it seems unlikely that that is the main or even an important advantage Linux has over Windows. After all, you can't really run old Linux binaries on a new Linux system without strong determination and a lot of time. There are many others, including its (essentially) fully open source nature definitely being up there.
csande17 8y ago
> Sure, you can fix it, you just might have to [...] say goodbye to running all the programs currently out there. One problem with doing this is that the only reason anyone uses Linux is to run programs that are currently out there. If Linux started to make breaking changes like this, people would switch to some other operating system that didn't break their software. Sure, lots of people use macOS, and macOS breaks a bunch of APIs every year. But macOS users also buy expensive recurring subscriptions for every app they use, so Mac software companies can afford to employ developers to clean up after Apple every year. Linux doesn't have that; a lot of Linux software is either unmaintained or maintained by volunteer developers in their spare time.

ordu 8y ago

> No, no one can fix this. I don't know about this mythical "one", but I can. I just see no reason to fix it. It is not so hard to make a patch for a /usr/src/linux/drivers/tty/vt.c to make it accept one more esc-seqeuence which would switch terminal into special state, when terminal will send keyup and keydown escape sequences instead of raw-keys for each keypress. A week of tinkering with vt.c and viola, terminal can send keyup and keydown. (Plus maybe one more week to decide how to encode keyups and keydown the best, so ideally terminal would be useable even after wrong esc-sequence sent to it in the wrong time). The right question is: and what? Why might I wish to do this? I might invent some application for this new feature, but I'm pretty sure I couldn't invent something useful what can't be done without keyup event.

derefr 8y ago
That doesn't fix it, on its own. You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. Can an ncurses program now detect a keyup through this? Can a Docker PTY? Can the JVM? Etc. In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.
- cryptonector 8y ago
  Exactly. There's more to it. And yes, it can be done, literally, and I'm sure several participants in this thread could do it. But there's practically no demand, so it won't get done.
- ordu 8y ago
  > You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.

zamalek 8y ago

> No, no one can fix this. The nice thing about escape sequences is that they are ignored if not understood. > Microsoft can't fix this either (in Windows Because it's not an issue in Windows? The Windows console, as primitive as it is, supports monitoring the status of the keyboard (which can be used to infer key up events).

cryptonector 8y ago
MSFT is adding a pty driver and support for Unix-style applications.
bboreham 8y ago
> The nice thing about escape sequences is that they are ignored if not understood. This is not what I find when I press my arrow keys in a container terminal set up with no TERM variable. I get funky characters spewed across the input line.

mikeash 8y ago

There are terminal emulators that can display images, make clickable hyperlinks, track the mouse cursor, and dynamically update the title bar with custom text. None of that was possible in the 70s. To say that this is impossible is to ignore how terminal emulators have actually evolved over the years.

darkpuma 8y ago
A typical modern terminal emulator running under X will export WINDOWID that is the X id of the terminal emulator window. With this you could detect key-up events. I've never seen anybody do this though. The only uses of this I've ever seen are detecting when the terminal emulator goes out of focus and drawing images on top of the terminal emulator. I've not done a detailed survey, but I believe this used to be the most common way of displaying images "in" terminal emulators before terminal emulators started supporting inline images encoded as escape sequences (e.g. iterm2) The problem with having the terminal emulator implement it is getting the terminal emulator to know when to insert these new key-up escape codes into the psuedo-terminal. The terminal emulator shouldn't send them to the psuedo-terminal when it's in raw mode, because every existing program that runs in raw mode won't know what to do with them. And inserting them into a cooked mode pty simply makes no sense. So it becomes clear that the terminal needs a "rawer than raw" (still bleeding?) mode, and some way for the program requesting bleeding mode to communicate that desire to the terminal emulator. Right now, that's not how the whole stack works. A program tells the psuedo-terminal (kernel) whether it wants raw or cooked mode, that's not something that terminal emulator is involved in. You could potentially have a terminal emulator that accepts a proprietary "toggle bleeding mode" escape sequence, at which point the terminal emulator starts inserting key up escape codes into the pseudo-terminal which it assumes has been placed into raw mode appropriately. There's not really any technical reason this couldn't be done, but there's a strong "nobody needs this" social reason for why it hasn't been done. Sure, if you want responsive controls while play aalib quake in your terminal emulator across ssh, you'd want this. But who does that as anything other than a gimmick?
cryptonector 8y ago
Making links clickable requires no changes to the protocols spoken -- the emulator merely recognizes URIs. I know about mouse support. Updating title bars actually goes back a long time. Displaying images... I've never seen -- can you tell me about that? I've actually outlined in this thread how to implement key up events, if that really was desired, in ttys, but I argue there's no real demand, and it won't happen. And it is impossible now in the sense that... the functionality does not exist.

gnachman 8y ago

> No, no one can fix this It's been solved twice, but I'd like to get that down to just once :) https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling https://sw.kovidgoyal.net/kitty/protocol-extensions.html#key... https://gitlab.com/gnachman/iterm2/issues/7440 https://gitlab.com/gnachman/iterm2/issues/7440