Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Comment (by wyardley): Honestly, the fact that you're still arguing when everyone else in the ticket has pointed out that there's a simple (and correct) workaround - that is, don't bind dsusp to `^`Y within your shell. I don't know if you're just embarrassed that you didn't realize the reason for this behavior or what, but I think your continued remarks (and continuing to re-open this ticket) make it clear that you are not planning on listening to what anyone has to say on this issue. Just because Mutt is more correct in accepting signals than other software does not mean that the behavior is incorrect. Mutt is not mainstream software; it's software mostly used by people who do care about things like having their terminal behave as they expect. Interestingly enough, I see this behavior in OS X, but primarily use Mutt on a FreeBSD system. On FreeBSD, while stty -a still shows "dsusp = `^`Y", the behavior is not the same. Installed via ports, but doesn't seem like any of the patches change this behavior. Have to say, I've been using Mutt on a number of systems for many years, and have never found myself accidentally hitting `^`Y, and I've never seen a single other complaint about this behavior on the mutt-users mailing list. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:18> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#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
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Comment (by balderdash): I never said mutt is the *only* program like this. Just that it doesn't have to be like this, since other software manages to avoid it without horrible side-effects. I also never said that Ctrl-Y is bad in every program. Just that it's bad in mutt (and *would* be bad in Vim for totally parallel reasons). I am mystified at the general response, which is effectively parodied thus: "So your popular class of OSes has made the decision to place important library L in a nonstandard directory N instead of standard location S and you want us to adjust the configure script so it can find L on your OS, like a whole host of other software does? We won't, because the fact that you can't build mutt against L is 100% your OS's fault, and the solution is obviously for you to just symlink or copy L into S, which is easy as pie.' The fact that your OS put L in N *deliberately* has magically granted that decision the following special status: no software should work around this decision even if the effects of L being in N are bad for a large class of users of that software on that OS, and neither-good-nor bad for everyone else. Indeed, the other software that manages to find N/L shouldn't be doing that. If they were designed well, they would *also* make everyone on your OS except a hypothetical two peoople create this symlink (it's easy!). If you don't like it, then you can just deal with a mutt that isn't built against L even though that demonstrably sucks, or you can file a bug with your OS because there's a realistic chance they'll listen. What's that you say? Some things a user shouldn't have to do themselves even though it would be easy for them to do so, and this sure looks like one of those cases? But this is not one of those cases, because it's easy for the user to do it themselves. We therefore close this issue." -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:17> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Comment (by balderdash): > Consider: you would like to use a dvorak keyboard layout in mutt, but qwerty in vi because your finger memory needs it. Would it be convenient for you to have a mutt option $interpret_qwerty_as_dvorak? Yes. But it's cleaner to remap your keyboard to dvorak outside of mutt. This is simply absurd. That would be a one-off, for mere convenience, and the inconvenience isn't due to a mutt defect or an OS foible. Nobody wants to accidentally suspend mutt, and the fact that mutt gets accidentally suspended by responding in that way to a prominent and central key is a mutt defect. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:13> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Changes (by brendan): * status: reopened => closed * resolution: => invalid Comment: Consider: you would like to use a dvorak keyboard layout in mutt, but qwerty in vi because your finger memory needs it. Would it be convenient for you to have a mutt option $interpret_qwerty_as_dvorak? Yes. But it's cleaner to remap your keyboard to dvorak outside of mutt. It's not just the bloat in mutt, it's clearly a layer violation. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:11> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX
-+--
Reporter: balderdash | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone:
Component: user interface |Version:
Resolution: invalid | Keywords:
-+--
Comment (by vinc17):
I don't see any reason to disable DSUSP in Mutt (except if it breaks
everything). I suppose that some users may want to use it, just like one
may want to use SUSP (Ctrl-Z). Moreover, the old setting could not be
restored if Mutt crashes or is killed (though the shell may provide a way
to restore the terminal settings).
If you never want to be able to use some terminal feature, then disable it
from your shell. Otherwise use a wrapper to disable/change what you want.
Things you may want to do for Mutt:
{{{
mesg n
stty dsusp undef 2> /dev/null
stty flush undef
stty pass8
stty -ixon
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:7>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX
-+--
Reporter: balderdash | Owner: mutt-dev
Type: defect | Status: reopened
Priority: major | Milestone:
Component: user interface |Version:
Resolution: | Keywords:
-+--
Changes (by barsnick):
* status: closed => reopened
* resolution: invalid =>
Comment:
{{{
On Fri, Sep 11, 2015 at 23:13:42 -, Mutt wrote:
This discussion should then essentially be about a design decision:
mutt is obeying SIGTSTP, some other applications apparently decide not
to do so.
SIGTSTP being on Ctrl+Y in MacOSX's terminal is Mac's design decision,
if that particular key is inconvenient to you, bark up a different
tree.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:14>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Changes (by vinc17): * status: reopened => closed * resolution: => invalid Comment: If everyone agrees that Ctrl-Y is a bad feature, then instead of introducing non-standard code in every application, the correct solution would be to drop DSUSP at the OS level. So, I suggest to report a bug against OSX. Thus every application would benefit from this. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:15> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Changes (by dgc): * status: new => closed * resolution: => invalid -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: new Priority: major | Milestone: Component: user interface |Version: Resolution: | Keywords: -+-- Comment (by dgc): This is not a mutt issue, it's a terminal property (DSUSP) that is applicable only on BSD-derived systems such as OSX. GNU glibc manual documents it thus: Macro: int VDSUSP This is the subscript for the DSUSP character in the special control character array. termios.c_cc[VDSUSP] holds the character itself. The DSUSP (suspend) character is recognized only if the implementation supports job control (see Job Control). It sends a SIGTSTP signal, like the SUSP character, but not right away—only when the program tries to read it as input. Not all systems with job control support DSUSP; only BSD- compatible systems (including GNU/Hurd systems). If you run `stty -a` you'll see ctrl-Y bound to DSUSP. DSUSP sends SIGTSTP just like SUSP (ctrl-Z) does, but ''only when the program reads the ctrl-Y as input -- not before''. If you run `cat` at your terminal prompt and press ctrl-Y and enter, you'll see the same thing. (You have to press enter because cat line-buffers input. Mutt does not.) To "fix" this, use stty to rebind DSUSP. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX -+-- Reporter: balderdash | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: invalid | Keywords: -+-- Comment (by balderdash): Vim doesn't do this. Nano doesn't do this. Less doesn't do this. Why must mutt interpret Ctrl-Y as DSUSP? Mutt won't even let me bind it to a macro. -- Ticket URL: <http://dev.mutt.org/trac/ticket/3780#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX
#3780: Ctrl-Y causes mutt to suspend on OSX
+--
Reporter: balderdash | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: user interface |Version:
Keywords: |
+--
On OSX 10.10.5, mutt from tip: start mutt, then hit Ctrl-y. Observe that
mutt is suspended and one is back at the bash prompt:
{{{
1]+ Stopped mutt
}}}
Nothing in the manual says that Ctrl-y should or would do this. No other
commandline software that I use is suspended like this upon hitting
Ctrl-y. Besides being annoying and surprising, it means one can't bind
Ctrl-y to anything.
It happens in Terminal.app and in iTerm, and in neither case have I
altered the terminal's default key settings to make Ctrl-y do something
special.
This behavior has been around for a long time, but I finally got sick of
it.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3780>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
