Re: flow-control

[Michael Schroeder]

On Wed, Dec 01, 2004 at 02:19:38AM +0100, Nikolai Weibull wrote:
> OK, an often revisited subject, but it just struck me that it's not
> working as I thought it would.  Why doesn't 'defflow off' disable
> flow-control in my terminals?  For most of my windows created by a new
> screen (with a $SHELL in them), I get something like
> 
>       (1,79)/(132,79)+8192 -(-)flow -c1 UTF-8 1(zsh)
> 
> in my info output, but for
> 
>       screen -t 'mua' 9 mutt -n
> 
> I get
> 
>       (6,19)/(132,79)+8192 -(+)flow app -c1 UTF-8 9(mua)

Which is exactly right -(+) flow means that flow is currently off but
would be on in automatic mode.

> What gives?  Without the 'defflow off' in my screenrc, I get -flow for
> most and +flow for the one with mutt in it.
> 
> In mutt, flow-control will be enabled.  In a terminal, [-(-)],
> flow-control is also still enabled, so the defflow off doesn't seem to
> have any real effect.  Is this due to xterm?  I thought I understood
> flow-control (finally), but it seems I don't.

Flow control is about who gets the ^S/^Q. If flow in on, screen will
handle it. If flow is off, the applications will. (Actually I'm
talking about the device drivers here, not programs.)

> Should I understand this as, even though screen passes on ^S, the shell
> will interpret ^S unless stty -ixon has been run

Not the shell but the devices driver, i.e. the PTY.

> and that in the case of
> mutt, there's really no chance for stty -ixon to be run?

If mutt doesn't set -ixon then there is apparently no need to get a
^S/^Q in it. Of course, if mutt then starts emacs, emacs will
set -ixon so that ^S will be received.

(So it is a bug in mutt if you have some keybinding to ^S and mutt
doesn't set -ixon... And it also won't work outside of screen.)

Cheers,
  Michael.

-- 
Michael Schroeder           address@hidden
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}