A concern about character "stranding" when using with-raw-mode etc.
hga@xxxxxx
(14 Aug 2019 16:10 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc. Lassi Kortela (14 Aug 2019 16:26 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc.
hga@xxxxxx
(14 Aug 2019 16:53 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc.
John Cowan
(14 Aug 2019 21:47 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc.
hga@xxxxxx
(14 Aug 2019 22:12 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc.
John Cowan
(14 Aug 2019 22:13 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc.
hga@xxxxxx
(14 Aug 2019 22:23 UTC)
|
Re: A concern about character "stranding" when using with-raw-mode etc. Lassi Kortela 14 Aug 2019 16:26 UTC
> I haven't done anything with line disciplines since the 1980s, but the > set, wait a bit, and reset paradigm of with-raw-mode etc. wasn't the > norm back then, a program like a version of EMACS would set raw mode and > stay in it, resulting in your having to blindly type reset^J if it > crashed without restoring the tty to cooked mode. Could it be that unnecessary short trips to raw mode were avoided because you couldn't rely on hardware terminals responding fast enough? > Is there any chance characters a user will be typing will get "stranded" > in the finite interval between calls to with-raw-mode? You mean at the time the Unix TTY driver is configuring stuff to switch between the modes? No idea, but it's one call to tcsetattr(), which seems to map to one ioctl() call nowadays, so it's unlikely. A realistic problem is that the Scheme thunk supplied to with-raw-mode will leave the extent of the with-raw-mode call before it has had the chance to restore cooked mode. with-raw-mode needs to have some unwind-protect-like behavior.