Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl From: karl@haddock.UUCP Newsgroups: comp.emacs Subject: Re: flow control by termcap Message-ID: <719@haddock.ISC.COM> Date: Mon, 13-Jul-87 12:49:40 EDT Article-I.D.: haddock.719 Posted: Mon Jul 13 12:49:40 1987 Date-Received: Tue, 14-Jul-87 04:58:23 EDT References: <493@yetti.UUCP> <13255@topaz.rutgers.edu> <13269@topaz.rutgers.edu> Reply-To: karl@haddock.ISC.COM (Karl Heuer) Organization: Interactive Systems, Boston Lines: 31 In article <13269@topaz.rutgers.edu> gaynor@topaz.rutgers.edu (Silver) writes: >ron@topaz writes: >> Changes EMACS makes to the screen are supposed to appear instantaneous. > >This depends upon your environment. It is impossible to perform >instantaneous screen updates in a "slow" atmosphere, ... Well, it doesn't *have* to be impossible -- when I wrote my own terminal emulator a couple of years ago, one of the features I wanted was to have screen updates *appear* instantaneous even at low speed. The idea would be that modifications to the screen would take place in an invisible buffer; the emulator would then make them all at once. Unfortunately, this particular feature was never implemented; for one thing, there was no general way to tell when the "last" update was done. (Some features I did put in: 3-byte DCA; 1-byte arrows; ^J as a real newline; and (experimentally) keyboard ^S (when flow control was enabled at the emulator level) put the emulator into local mode until a keyboard ^Q was received. I really grew to like that last one!) (Now, let's justify posting this to comp.emacs.) There's one feature I didn't think of at the time, but would have been quite useful. Somewhere, in the chain of devices, switches, programs, and protocols that eventually led to an emacs, there was at least one gnome that insisted on processing ^S/^Q. I could have made an emacs-mode in which keyboard ^S, ^Q, and (say) ^R would map to ^RS, ^RQ, and ^RR, respectively; then had emacs* perform the reverse translation at the lowest possible level. This would've made the flow-control braindamage completely transparent. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint *It would be better to put this in the kernel, but I didn't have that option.