5 ms·

There are terminal emulators that can display images, make clickable hyperlinks, track the mouse cursor, and dynamically update the title bar with custom text.

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.
- darkpuma 8y ago
  iterm2 supports inline images with a proprietary set of escape codes described here: https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html Incidentally if you ssh into an untrusted system using iterm2 (or otherwise get foreign escape codes going into iterm2, for instance if you cat the wrong file), I believe it's possible for that system to drop files into your ~/Downloads/ directory without prompting you. It could be worse though, there used to be terminal emulators you could exploit by setting the title, because they weren't bounds checking correctly.
- mikeash 8y ago
  I’m not just talking about clickable URLs, but actual hyperlinks where the visible title is different from the destination URL. I don’t know what there is to tell about displaying images. There are terminal emulators that can display images inline when a program emits the image data properly. I don’t understand your final sentence. How does it make sense to say that it’s impossible because it doesn’t currently exist? That’s like saying it’s impossible for me to drive because I’m not currently in a car. You didn’t say that nothing currently supports it, you said “no one can fix this.”
  - cryptonector 8y ago
    I wrote this: > So, yes, it's absolutely impossible to get key up events in tty context, and at this point it will almost certainly stay that way forever, as it's too late to retrofit terminal emulators, drivers, and applications to understand whatever protocol for communicating key up events. (The right way to do this would be to develop an escape sequence protocol that the tty/pty drivers could decode and turn events into out-of-band events to be delivered via ioctl()s, that way applications that don't care about key up events don't see them and don't need to be modified. But who is going to do all that work?) So "it's impossible [right now]" and "it can be done" but "it's not gonna happen". Is that not a fair summary? Perhaps we can disagree as to the last part. EDIT: Ah yes, further below I wrote this: > 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. That's overbroad, yes. The fix I outlined is not as much as boiling great lakes.

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.

darkpuma 8y ago
iterm2 supports inline images with a proprietary set of escape codes described here: https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html Incidentally if you ssh into an untrusted system using iterm2 (or otherwise get foreign escape codes going into iterm2, for instance if you cat the wrong file), I believe it's possible for that system to drop files into your ~/Downloads/ directory without prompting you. It could be worse though, there used to be terminal emulators you could exploit by setting the title, because they weren't bounds checking correctly.
mikeash 8y ago
I’m not just talking about clickable URLs, but actual hyperlinks where the visible title is different from the destination URL. I don’t know what there is to tell about displaying images. There are terminal emulators that can display images inline when a program emits the image data properly. I don’t understand your final sentence. How does it make sense to say that it’s impossible because it doesn’t currently exist? That’s like saying it’s impossible for me to drive because I’m not currently in a car. You didn’t say that nothing currently supports it, you said “no one can fix this.”
- cryptonector 8y ago
  I wrote this: > So, yes, it's absolutely impossible to get key up events in tty context, and at this point it will almost certainly stay that way forever, as it's too late to retrofit terminal emulators, drivers, and applications to understand whatever protocol for communicating key up events. (The right way to do this would be to develop an escape sequence protocol that the tty/pty drivers could decode and turn events into out-of-band events to be delivered via ioctl()s, that way applications that don't care about key up events don't see them and don't need to be modified. But who is going to do all that work?) So "it's impossible [right now]" and "it can be done" but "it's not gonna happen". Is that not a fair summary? Perhaps we can disagree as to the last part. EDIT: Ah yes, further below I wrote this: > 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. That's overbroad, yes. The fix I outlined is not as much as boiling great lakes.