From: John Cowan <xxxxxx@ccil.org>
Date: Friday, August 09, 2019 10:49 AM

On Fri, Aug 9, 2019 at 11:28 AM <xxxxxx@ancell-ent.com> wrote:

[ Keep fifos. ]
 
[ 80/29 remove get parent process ID. ]

Thus, and for simplicity's sake, I strongly advocate exposing the calls that these will use to simply set the line discipline to raw, maybe rare (completely left out of the SRFI, do we want it??), no echo and echo (orthogonal, I think), and cooked mode.

That's exactly what I've got now

Eh, you've got a particular high level interface to these line disciplines, which is UNSAT for people who perceive time in significantly less than 1 second intervals.  So I would say (see next paragraph), in addition to providing your high level interface, expose low level procedures that'll have the code your's must have, simply to set a new line discipline, and keep it until set to something else, or the program ends.

Except, wait a second, when you do that, it stays after you've exited!  It's been so long since I ran e.g. EMACS on a single real or virtual terminal I forgot the fun of blindly typing in "reset^J" (linefeed, not carriage return!) to regain to cooked mode.  And now I get the raison d'etre for your line discipline I/O suite.  Which if you'd just allow setting timeouts to 1/10 second or so granularity I suspect I'd come to really like.

although it should be refactored to treat cooked/raw/rare as equals.  Treating cooked and echo as the default and returning to it by dynamic-wind makes a great deal of sense to me.  That gives us two procedures:  (with-terminal-mode rare? thunk) and (with-no-echo thunk).

Per the above, that default you get by "reset" of cooked and echo is pretty much required.  But do we want to make mode and echo orthogonal?  Is there any circumstance where you'd like raw or rare mode not echoing?  Many web user interfaces and e.g. Gnu Emacs "echo" password characters with "."  Which does give an attacker looking over your shoulder a very important piece of information, but it seems to be accepted, and I think it significantly decreases password entry errors.

Is there any other (non-evil :-) use case for no echo than typing in a password or pass phrase??

- Harold