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!

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.