[comp.sources.d] termcap, flow control, emacs

ford@crash.CTS.COM (Michael Ditto) (06/20/87)

In article <5988@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Railing against the use of DC3 and DC1 for flow control by some terminals
>is pointless [...]

No, it is like fighting against slavery or aparthied or sex discrimination;
after we are rid of them, people will think "gee, remember when people used
to have slaves, when women coudn't vote, when in-band flow control was used?"
(ok, exaggeration admitted).  In-band flow control is necessary because of
ancient protocols (like voice-line modems) that can not have out-of-band
flow control.  But we people who know better can still complain and choose
more intelligent alternatives when they are available.

>If your terminal requires support for DC3/DC1 flow control, you should so
>inform the UNIX terminal handler, which will make sure the DC3/DC1
>characters are not seen by the application.  You should also have the "xo"
>Boolean capability set in the termcap entry.  If in spite of this, your
>copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them
>as user command keystrokes, then your EMACS is in need of repair.

I find it very convenient to have XON/XOFF flow control enabled when I am
not in Emacs, it allows the terminal to keep up with output from normal
commands.  But in Emacs, this is useless, as never more than a screenful of
output is given.  Therefore, it makes sense for Emacs to DISABLE XON/XOFF in
the terminal driver.  If someone has a terminal that is so losing as not to
be able to receive and display one screen of text without flow control,
Gnu-Emacs (why would anyone use anything else?) allows flow control to be
activated by the expression (set-input-mode nil t) in the .emacs file.

The method of flow control is not really related to the protocol for cursor
motion, etc., so an 'xo' capability is silly.  Flow control is at a different
level of communication protocol than termcap.  Editors should use the tty
driver's current flow control information if they have a need to be aware of
flow control methods (and they normally shouldn't).

> [...]  (You should also get out
>of the habit of using any key bindings containing ^S or ^Q.  That was a
>really stupid set of defaults in the first place.)

Again, I feel that the ancient protocols should not be encouraged in any
new products.  Allthough Emacs should (and does) give a way for old-fashioned
terminals to work, there is no need for the default command set to be
crippled because of it.  Also, part of the "definition" of an Emacs editor
is its "standard" Emacs command set as originally designed, and passed down
through the generations of hackers.
-- 

Michael "Ford" Ditto				-=] Ford [=-
P.O. Box 1721					ford@crash.CTS.COM
Bonita, CA 92002				ford%oz@prep.mit.ai.edu

james@cantuar.UUCP (J. Collier) (07/02/87)

    Some terminal emulators automatically send Xoff/Xon pairs when local
actions - such as a menu seletion to re-define mouse-click interpretation -
are invoked. 
    This is clearly undesirable in emacs, but may be necessary elsewhere. 
If the terminal/emulator has a flow control disabling sequence, GNU-emacs users
may find the following ".emacs" entries of use:

(send-string-to-terminal "<disable sequence>")
(defun t925-suspend nil
         (interactive)
         (send-string-to-terminal "<enable sequence>")
         (suspend-emacs)
         (send-string-to-terminal "<disable sequence>") )
(defun t925-kill nil
         (interactive)
         (send-string-to-terminal "<enable sequence>") 
         (save-buffers-kill-emacs) )
(global-set-key "\C-x\C-z" 't925-suspend) 
(global-set-key "\C-x\C-c" 't925-kill)
 
  [No flames if there's an easier way, please; I am not a regular emacs user]

BTW is it my imagination, or does GNU-emacs (v17.64) not know the difference
between the "in" and "im" insert-mode styles for 4.3BSD termcap? Having gone
to some trouble to add "im" to my pet terminal emulator, I now find I must
disable the termcap entry for emacs's pleasure. What gives?
-------------------------
James Collier  (james@cantuar.uucp / {watmath,munnari,mcvax}!cantuar!james
Computer Science Dept., University of Canterbury, Christchurch, New Zealand.