@hanshuebner I don't really understand what you mean,...

@hanshuebner I don't really understand what you mean, I think it's obvious that "readline" exists at a very different level than the terminal driver?

what's interesting to me is that from a user’s perspective it's very unclear which things are being handled by the OS and which are passed through to the application and they're just kind of chaotically mixed together

Like 29 October at 20:47 | Open on social.jvns.ca

2 comments

Hans Hübner

@b0rk I don't think that it is all that obvious that readline is not part of the driver. Providing kernel-level line editing basically was a necessity in the 16bit era, but when machines got more powerful, providing these things in user mode became more common.

What that also meant is that there was no single line editing system, but each user-mode program could (and needed) to provide its own. GNU readline, albeit popular, was really hindered by its license.

29 October at 20:55 | Open on mastodon.social

Hans Hübner

@b0rk With a user-mode line editor, it is only the control characters that generate interrupts which require driver support, and modern implementations don't even need to rely on the driver to send signals (i.e. they treat Ctrl-C like any other character and send a SIGINT if they want to).

29 October at 20:57 | Open on mastodon.social