[HN Gopher] Raw keyboard handling in Unix terminals
___________________________________________________________________
Raw keyboard handling in Unix terminals
Author : drran
Score : 93 points
Date : 2021-05-18 12:22 UTC (1 days ago)
(HTM) web link (sw.kovidgoyal.net)
(TXT) w3m dump (sw.kovidgoyal.net)
| voldacar wrote:
| This feels like the computing equivalent of epicycles in medieval
| physics.
|
| Will we ever just admit that the vt100 tty is just no longer
| suitable as a basic OS abstraction, and needs to be torn out and
| replaced? Or in 50 years will simple interactive programs still
| not be able to detect keyup without importing a bunch of bloat
| from x11/wayland?
| tyingq wrote:
| I suspect in 50 years that we will have lost control of the
| local compute end of things. Our new "dumb client" will be some
| future iteration of a web browser. And you won't be allowed to
| run anything outside of it. You'll be able to see keyup, but
| most of everything else will be on somebody else's server.
| jrumbut wrote:
| Over the last 50 years there have been a few cycles between
| thin and thick clients (in different contexts) so hopefully
| it's not all one direction from here.
| agumonkey wrote:
| I wonder if these cycles have been studied.
| tyingq wrote:
| I agree, though this time there's big money behind taking
| local control away.
| generalizations wrote:
| Which is why, as long as there's hackers, there'll be
| another cycle in the other direction.
| tyingq wrote:
| They aren't having much luck with the iPhone...
| kingofclams wrote:
| Take what i say with a grain of salt, (I'm not an iPhone
| hacker and I follow their work semi-loosely but from my
| understanding there are a number of available and
| documented tethered exploits. I wouldn't doubt theres a
| number of untethered exploits that are waiting in Apple's
| bug tracker system, or are simply too abusable for the
| general public to know about.
| w0de0 wrote:
| The are! It's just not an everyday occurrence - and so is
| worth much more - so most zero days end up in nation
| state hands.
| saurik wrote:
| The thick clients, though, seem heavily tied to mechanisms
| that still prevent local control.
| sprash wrote:
| If anything the vt100 ttys are just as suitable as ever.
| Command line interfaces are superior even today because the
| step from interaction to automation is as minimal as possible.
| I predict that the futuristc VR GUI of tomorrow will still be
| just a bunch of vt100 terminals floating in space.
| voldacar wrote:
| Can't we dream bigger though? For instance, I feel like
| templeOS's command line is unironically _conceptually_
| superior than the linux commandline or any other unix. I
| should be able to mix text with 3d models or images or sound,
| pipe them between programs, etc. I should be able to pause a
| running program, save it to disk, and resume it later. There
| are all sorts of things that I should be able to do but can
| 't, because of the deliberate unix fetishization of 1970s era
| computing.
|
| >Command line interfaces are superior even today because the
| step from interaction to automation is as minimal as
| possible.
|
| Agreed completely. In fact, the OS should force GUI programs
| to all speak a coherent language so that you can automate
| them and pipe data between them. And if the machine is going
| to serve the user, the user should be in control of the GUI,
| they should be able to move buttons and UI elements around
| into the configuration they prefer. This would only be
| possible if GUI programs had minimal control over actual UI
| layout, which would make webdevs angry. But given the state
| of web UI, I think that's an acceptable sacrifice.
|
| Much of the above was possible in lisp machines. But sadly I
| don't think it would be possible to create such an OS today
| (unless the "OS" is running in a linux VM and using linux for
| the actual hardware interface) due to the sheer diversity of
| hardware. And the closed source nvidia driver would ensure
| that you never got cool graphics.
| taeric wrote:
| I think the problem is conflating "dreaming big" to "no
| restrictions." A large part of the strength of the current
| terminal approach is specifically its limitations.
|
| That is to say, a large part of what makes the automation
| capabilities of most terminal applications so strong is
| specifically that the idea of character streams over raw
| binary streams being the default.
|
| Can I dream of a lisp machine that lets me do what you are
| suggesting? I mean, sorta. Early HTML based apps came
| pretty close on this, but folks regularly refuse to limit
| themselves to a base set of constructs. Is why it would be
| easy to user style HN, but basically impossible to do the
| same to gmail. (gmail, amusingly, created their own theme
| capabilities...)
| sprash wrote:
| In my opinion the mistake was to move away from the
| terminal in the first place. Many gui commands like "draw
| button in bottom right corner" could be done via escape
| codes and creating a gui program would be as simple as
| writing a bunch of commands to stdout. As far as I know the
| earliest prototypes of X worked just like that.
| bool3max wrote:
| Well, X developers must've abandoned that idea for a
| reason.
| sprash wrote:
| X was meant to be a lowest common denominator for Unix
| workstation vendors to base their proprietary software,
| window managers and desktop envrionments on. Too much
| standardization at that point would have meant less
| distinguishing features for their products. Today all
| major unix workstation vendors are dead which shows they
| were clearly wrong.
| nine_k wrote:
| There is a library for doing things like that; for some
| reason, it's called "curses".
| rootbear wrote:
| I believe that's how the MGR window system, from
| Bellcore, worked. I fiddled around with it briefly on an
| old Sun Workstation many years back.
|
| https://en.wikipedia.org/wiki/ManaGeR
| [deleted]
| otabdeveloper4 wrote:
| > no longer suitable
|
| No way, it's way more popular and useful than ever.
|
| We just need to ditch vt100 and settle on some sort of xterm
| variation as the new standard.
| blueflow wrote:
| This won't have much effect, since xterm is an DEC VT
| emulator.
| rbanffy wrote:
| If I read this correctly, this proposal aims to solve just that
| kind of stuff while remaining compatible with all the legacy
| software in use today.
| Conlectus wrote:
| Excellent to see, the ESC ambiguity problem is one that has
| especially bugged me.
|
| I hope there's a plan to standardize this with the relevant
| organizations! I worry that's the only way to see widespread
| adoption.
| nine_k wrote:
| Yes, I can imagine a mostly-backwards-compatible, but much
| improved, standard; let's call it VT-2021.
| drran wrote:
| If you are native English speaker, then start with kind of
| "caniuse" site, but for terminals and VT, please. It will
| help a lot if we will be just aware of available features in
| existing terminals and their compatibility with standards.
| nine_k wrote:
| Not a web site, but terninfo and termcap databases,
| normally present on a Unix system, have this information.
|
| I would hazard to say that some basic subset of VT100
| commands is "universally" supported, even on Windows if one
| uses Windows Terminal.
|
| Various obscure high-end features from 1980s, like
| programmable font bitmaps, or sixel support, much less so.
|
| Also, modern terminals support Unicode, including emoji (as
| double-width symbols), which was unimaginable in 1980s or
| 1990s.
| DHowett wrote:
| > if one uses Windows Terminal.
|
| This is also true of the Windows Console as of Windows
| 10. Any VT100 (also VT220, VT4xx, VT5xx, xterm ...)
| support we add to Terminal eventually flows out to the
| console host integrated into Windows. :)
| drran wrote:
| How to display terminfo in a consumable way?
|
| What about non-standard features, like drawing, sixels,
| sound, mouse, touches, clipboard, fonts, true color,
| transparent background, color emoji, double size text,
| etc.?
| saurik wrote:
| And yet, I feel like that database doesn't succeed in
| replacing a website that tells me "the following
| terminals support OSC 8 and with what awkward
| limitations", which is knowledge I find both useful and
| important for web browsers despite being able to do
| runtime tests to determine the support of most features.
| "Oh, it turns out 78% of my users wouldn't be able to
| parse OSC 8 even if I went to the trouble of using it...
| maybe I'll work on a different feature today".
| amelius wrote:
| This should be an RFC.
| softblush wrote:
| The usual name clash rant. Why kitty? KiTTY is a fork of PuTTY
| and has been around since at least ~2007 or so
| mongol wrote:
| "Emit the escape sequence CSI < u at application exit or just
| before leaving alternate screen mode to restore the previously
| used keyboard mode."
|
| What happens if the application crashes without emitting this?
| The user is dropped in to the shell and the terminal and shell
| might misbehave together?
| amadeusz wrote:
| I guess same thing that happens to any application that sets
| weird modes. You should use 'reset' command which just emits
| escape code to reset terminal and terminal emulator hopefully
| sets everything back correctly.
| tedunangst wrote:
| If the application switched to key press mode, you're not
| going to be able to type reset.
| amadeusz wrote:
| Well, from what I've read all alphanumeric can be typed
| just fine, they go as is to terminal, problem is with
| special keys that some of them emit escape sequences that
| confuse shell or combinations of those.
|
| But not to trust what I just read I've installed kitty and
| tested it and you can type in the "reset" just fine. I hit
| a bit of a problem with "Entering" it, as apparently if you
| have numlock enabled (which I do on login) pressing "Enter"
| sends escape code: "^[[13;129u", but if you disable numlock
| it is typed in as per documentation: "0x0d - for the Enter
| key", which in any ascii table is Carriage Return.
|
| And yes, issuing reset restored normal terminal operation.
| tedunangst wrote:
| If you enable all key events there's going to be a "key
| release" event between the r and e and all subsequent
| letters of reset.
| gonzus wrote:
| This is awesome. For a long while I have wanted to write
| character-based applications with greater control of the
| keyboard; think "a terminal tetris that can recognize key
| combinations such as Alt-I, Ctrl-J, Alt-Ctrl-PgUp, Meta-Ctrl-F14,
| etc." This should work OK whether running locally on the console,
| on a (serial) terminal, on a graphical (X Windows / Wayland)
| terminal, on a remote (SSH) terminal, etc.
|
| I wish something like this was also created for the mouse, so
| that you could use your mouse everywhere (including the console
| without any graphical environment running), remotely over ssh,
| etc. I see no reason why a similar protocol could not transmit
| mouse events over ssh and allow you to interact, using your
| mouse, with a remote character-based application.
|
| I would love for such proposals to gain traction and be accepted
| everywhere.
| smhenderson wrote:
| Have you heard of gpm[1] - general purpose mouse? Slackware
| offers to install and enable it by default, even these days.
|
| It's a terminal based mouse server. ncurses supports it so it's
| theoretically possible to do all the same things in a TUI that
| you would in a GUI with a mouse.
|
| [1] https://en.wikipedia.org/wiki/GPM_(software)
| drran wrote:
| GPM is for console, not for terminal. I used it a lot in
| virtual console, before switching to X11 based terminal
| emulators.
| sprash wrote:
| There are already several standardized mouse protocols
| available some even with pixel precision. The most complete
| implementation of those protocols has xterm. They can be tested
| with a program called "vttest".
| amadeusz wrote:
| The thing I would like to see is this making it into terminfo
| entries, meaning that it is possible to detect that terminal
| supports this behaviour, otherwise while great it is terminal
| emulator specific.
___________________________________________________________________
(page generated 2021-05-19 23:01 UTC)