[prev in list] [next in list] [prev in thread] [next in thread]
List: mutt-dev
Subject: Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
From: Mutt <fleas () mutt ! org>
Date: 2015-09-13 4:40:38
Message-ID: 057.bd5f5051cadbeaa04c6a30ce7077424d () mutt ! org
[Download RAW message or body]
#3780: Ctrl-Y causes mutt to suspend on OSX
-----------------------------+----------------------
Reporter: balderdash | Owner: mutt-dev
Type: defect | Status: closed
Priority: trivial | Milestone:
Component: user interface | Version:
Resolution: invalid | Keywords:
-----------------------------+----------------------
Comment (by dgc):
Balderdash, as tempting as it is to go point for point with you, I don't
think that serves any purpose. Your paraphrasing of the argument is a
straw man, not what we're actually telling you. So far nobody but you has
disagreed with our stance. This is very simply an OS issue. Other
applications (but not most, by far) choose to sidestep the OS behavior.
Mutt does not, and we feel there are good reasons for that. I think we've
been pretty clear that this actually is harmful, not just a trivial bug
that we refuse to fix. I've already spent more time researching and
arguing than it would take to patch, commit, release, and announce an
update.
I was curious about those applications that you hold as models though. I
wanted to be confident that there's no reasonable way of doing what you
asked — confident that I was not overlooking some smarter approach than
what I knew about already. After all those vim guys are pretty smart. So I
took a harder look at what vim does to reclaim !^Y. It turns out it's not
really aiming for !^Y, that's just a side effect. What vim actually does
is to disable ''all'' terminal-generated signals by the C (termios)
equivalent of "stty -isig". Vim blocks !^C, !^Z, all of them, so that on
keyboard read it actually receives those control characters (\003, \031,
\032) instead of job control signals. Then vim explicitly maps !^C and !^Z
in its keyboard bindings to interrupt and suspend, respectively, and when
those keys are struck it sends itself an interrupt or suspend signal.
Well, what if I've remapped INTR and SUSP in my terminal? (It doesn't
matter why I might do that; the point is UNIX allows it and an application
shouldn't subvert that.) What about vim? ''Vim totally subverts that.''
Try this experiment: `stty susp ^P` to set !^P to suspend in your
terminal. It works. Run any normal program; !^P will suspend it. That's
how UNIX is supposed to work. You can rebind terminal signal generation.
Now run vim. Press !^P — nothing happens. Press !^Z — it suspends. Vim's
approach means that it doesn't follow what the user or system has
configured. I argue that's completely broken and vim has absolutely done
the wrong thing.
Your argument is that nobody wants !^Y anyway, so I imagine you would also
argue that nobody does (or, at least, should) rebind INTR and SUSP. But
this is not mutt's decision to make. The OS provides these configurable
capabilities for a reason. Because it provides them, there can be people
who use them. If someone uses them, and they run mutt and find that it
prevents what their OS allows, ''that is a mutt bug.'' As Brendan said,
that's a layering violation.
Emacs? Same result as vim. Broken. Pine? I don't know, I use mutt.
Netstat? I can't imagine why netstat is doing ''anything'' with raw
keyboard bindings anyway, so I don't really care. Less? Less does what it
should, if it's going to disable !^Y. Less is okayish. Sudo? Sudo is not
the same class of program. It's like ssh, it allocates a pty and owns that
terminal. You get the new terminal's behavior, not the old one's. Not
analogous at all to mutt. (But try "sudo cat", i.e. run sudo without
allocating a pty. Now !^Y suspends.) So you have one case of something
else that does what you're proposing.
Google around for people asking why !^Y suspends their software. The
answer is always "stty dsusp undef" or something like it. In every case I
found, the OP is glad for an answer and happily accepts the solution.
You're the only person I've ever heard unhappy with using what the OS
gives you to control your operating environment, and asking for the
application to circumvent it for you to save you one line in a shell
config file. That is, as you say, not remotely compelling.
Mutt should not be making these decisions. Neither should vim, emacs, or
netstat.
If you want a wrapper, here's one. But you don't. You don't want DSUSP at
all, so just put the stty in your .profile and call it a day.
{{{
#!/bin/sh
# Disable DSUSP processing while running mutt
# Capture old termio params
old=$(stty -g)
# Disable DSUSP
stty dsusp undef
# Set a trap to restore termios
trap "rc=$?; stty $old; exit $rc" 0 1 2 3 15
# Run mutt
mutt "$@"
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:20>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic