#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

 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

 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.

 # 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

Reply via email to