TerminalsCowan proposal

[johnwcowan]

TerminalsCowan is loosely based on the termbox API, but I have attempted to make it implementable on a Windows console and even an HTML textarea.

[lassik]

Here as in so many places, we should make a survey of the backends and extract the common features.

I have most of an ANSI codes survey in my head; it just has to be written down and all the details filled in.

If we get stuck with Unix terminals, Tom Dickey and jdebp are two wizards who know about everything there is to know about them; both still active on the net.

[johnwcowan]

One idea I had was to eliminate 99% of all termcap crap by saying that when we do a term-sync to draw the screen, we just clear it with the ANSI sequence "\e[H\e[J" (other terminal types? fuggedaboudit!) and redraw it from scratch. This fits well with HTML and with (what I understand of) the Windows terminal API. 9600 baud is no longer an upper limit (I vividly remember when it was eight times the upper limit, kaff kaff) and we shouldn't hesitate to ditch old strategies that are overengineered for 99.9% of all modern conditions.

Granted, I wouldn't want to implement an editor this way, as it would flicker too much. But most TUI programs seem to be not editor-like but menu-like.

[lassik]

Agreed completely on termcap/terminfo. No-one apart from a few experts understands how to work with those databases, so the entries are missing or incomplete a lot of the time anyway. Terminal emulators are standardized enough that we can amass a very nice collection of codes that work practically everywhere.

Screen flicker is typically combated by keeping an in-memory copy of the old and new screen contents, computing the difference, and only writing the changed parts to the screen. The cursor can be hidden during the screen update to further reduce flicker; that ought to be reasonably portable nowadays. iTerm2 has novel escape sequences to freeze the screen during an update and unfreeze it when done, but I don't know of any other emulator that has those yet.

[lassik]

"Terminal emulator" is kind of a funny term nowadays, given that the emulators have many more capabilities than the now-imaginary hardware they supposedly emulate. Alternatives:

• Terminal leapfrogger
• Terminal forever
• Terminal millennium edition
• Son of terminal
• Terminal 2: electric boogaloo

[lassik]

And of course, something about the undead. With apologies for the bad humor.

[johnwcowan]

Screen flicker is typically combated by keeping an in-memory copy of the old and new screen contents, computing the difference, and only writing the changed parts to the screen.

That's what curses and its competitors do, yes. But a simple portable implementation along the lines I described, with just clear-screen and change-color, means it needs no FFI, at least on non-Windows systems. I just tested the following shell script:

trap 'stty echo; exit' 2
stty -echo
while true; do
  tput clear
  pbpaste
  read
done

where foo is a short text file that fits on the screen. Hitting ENTER causes it to redraw quickly enough on this Mac that I see no flickering whatever.

[lassik]

I tried the script and I get:

• Regular flicker Apple's Terminal app.
• Constant flicker on iTerm.
• Even worse flicker on Alacritty (a GPU-accelerated terminal).

It seems the "better" (i.e. more responsive) terminals flicker more.

This is a pretty fast computer so we can expect that flicker won't be unusual.

[lassik]

We don't need FFI for curses either if we write one of those subprocess wrappers in C. But for most implementations it'll be simpler to link to libncurses. Java has some curses equivalents that JVM Schemes can use.

[lassik]

Flicker won't be fully solved before those iTerm freeze/unfreeze codes are ubiquitous. But the next best thing is hiding the cursor and redrawing the changed parts as best I can tell.

[lassik]

@johnwcowan, can you move TerminalsCowan into this repo so we can start iterating on the API?

[johnwcowan]

It's a big pain to move a single file from one repo to another while preserving the history, and this is going to be recurring. I suppose I could just copy each file into the new repo as I go, leaving the history behind. What do you think?

BTW, I think it is better for the spec not to be the README.md, but just make that a short paragraph about the idea. The spec can then go into spec.md or whatever.

On Sun, Oct 18, 2020 at 9:06 AM Lassi Kortela notifications@github.com wrote:

@johnwcowan https://github.com/johnwcowan, can you move TerminalsCowan into this repo so we can start iterating on the API?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/cell-terminal/issues/2#issuecomment-711165368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPPBQ35A6OKYBN2BKM27TSLLR5JANCNFSM4SM5FMWA .

[lassik]

It's a big pain to move a single file from one repo to another while preserving the history, and this is going to be recurring. I suppose I could just copy each file into the new repo as I go, leaving the history behind. What do you think?

I agree. git filter-branch is the traditional way to do this, but I've forgotten how to use it. Since the existing pre-SRFIs mostly come from r7rs-work, I can try to write a shell script with the right incantations for that repo that takes the filename of one .md file as an argument. It then splices the history of that file into another repo.

BTW, I think it is better for the spec not to be the README.md, but just make that a short paragraph about the idea. The spec can then go into spec.md or whatever.

The advantage of having the draft itself in README.md is that it saves a click in the GitHub UI which shows the README contents on the front page of each repo. Otherwise I don't have an opinion either way. Arthur will want to move the draft into a .html file when the SRFI is submitted; since we don't use .html files for the pre-SRFIs, files will have to be moved/generated at SRFI submission time no matter which option we pick.

[lassik]

The Abstract section of a SRFI is meant to be a short paragraph about the idea, so we could have the draft in README.md and fill in the abstract?

[johnwcowan]

Works for me.