A very first-draft proposal for character-cell terminals
John Cowan
(04 Aug 2019 16:58 UTC)
|
||
Re: A very first-draft proposal for character-cell terminals Lassi Kortela (05 Aug 2019 16:17 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: A very first-draft proposal for character-cell terminals
John Cowan
(05 Aug 2019 21:32 UTC)
|
||
Re: A very first-draft proposal for character-cell terminals
Amirouche Boubekki
(05 Oct 2019 11:10 UTC)
|
||
Re: A very first-draft proposal for character-cell terminals
Arthur A. Gleckler
(05 Oct 2019 18:56 UTC)
|
||
Re: A very first-draft proposal for character-cell terminals
Amirouche Boubekki
(06 Oct 2019 07:07 UTC)
|
||
Re: A very first-draft proposal for character-cell terminals
John Cowan
(13 Oct 2019 19:43 UTC)
|
Re: A very first-draft proposal for character-cell terminals Lassi Kortela 05 Aug 2019 16:17 UTC
> This is about as simple as it could be, but hopefully no simpler. It's > designed for the world of Windows consoles and terminal emulators, not > 9600 baud dialup links. Critique invited, and I'm sure there will be > plenty to critique! > > https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/TerminalsCowan.md John, this is great! I agree with the general approach of "it's just a character grid", as we discussed a couple months ago. I did that exploration of sensible terminal primitives we talked about, but hit a wall. Basically there are two scenarios: 1. Program uses the entire screen. 2. Program uses the screen from the line with the cursor on down. Case 1 corresponds to curese, case 2 corresponds to line editors such as readline and its fancier counterparts. Case 1 should draw on the "alternate screen" of terminal emulators. Case 2 should probably draw on the main screen [obligatory "all your base" joke here]. The main screen is where the readline prompts from all your familiar programs go currently. The alternate screen where things like less, vim and emacs draw things. The reason why your readline prompts are preserved when you quit 'less' is because less drew everything on the alt screen. I'd like to try writing a "no crud shell" - like bash, but doesn't let any terminal crud from failed screen updates show on your screen. Would it be possible without putting new ioctl() interfaces into Unix terminal drivers? Basically whenever you run any shell command, it would open a pty (pseudo-terminal) and run that command in the pty. The stuff the command wrote to the pty would be scrutinized for any crud, and this "no crud shell" would make sure that only good control codes are passed through to the real terminal emulator. Haven't thought about the details yet. But if such a feat could be accomplished, it would teach us what a sane terminal interface is, so that after untold decades we could finally get the daily terminal crud off our screens for good.