Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-12 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-12 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-12 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-11 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-11 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-11 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-11 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-11 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-10 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-10 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent



Re: [Mutt] #3780: Ctrl-Y causes mutt to suspend on OSX

2015-09-10 Thread Mutt
#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: 
Mutt 
The Mutt mail user agent