GNU bug report logs - #16617
24.3.50; REGRESSION: `C-q ?' pops up annoying *Char Help* buffer

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sat, 1 Feb 2014 19:17:02 UTC

Severity: minor

Merged with 17371

Found in versions 24.3.50, 24.4.50

Done: Leo Liu <sdl.web <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16617 in the body.
You can then email your comments to 16617 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Sat, 01 Feb 2014 19:17:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 01 Feb 2014 19:17:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Sat, 1 Feb 2014 11:15:45 -0800 (PST)
This is a regression.  `C-q ?' pops up an annoying "*Char Help*" buffer.

What is said here for `?' is also true for `<f1>'.  It is not true for
`C-h', however.  The char inserted when using `C-q <f1>' is `^@'.
`<f1>' is not a character, so it should not cause a character to be
inserted.

1. The text in this help buffer is not formatted (e.g. filled)
   correctly.

2. The doc string for `quoted-insert' does not even mention this bizarre
   `?' behavior.  Nor does this behavior seem to be documented elsewhere.
   It is not even listed in NEWS as a change (an incompatible change, no
   less).  The behavior for `<f1>' is not new, but it too is not
   documented in connection with `C-q' AFAICT.

3. This *Char Help* buffer should not be popped up at all - for ANY char
   that you type after `C-q'.  This is a misfeature.  `?' should just be
   inserted, with no noise.  It should certainly not be interpreted as
   a plea for help.

4. With `emacs -Q', you might not even notice the popped-up *Char Help*
   buffer, which means that it does not even do what the enhancer
   presumably intended.  It just flashes for an instant - impossible to
   read it, and serving no purpose but to annoy and puzzle.  This alone
   is a regression wrt previous Emacs releases.

5. In other contexts it can be even more annoying: (a) The help really
   is shown.  (b) It can remain shown, requiring the user to remove it.
   (c) That can even involve requiring the user to change buffers and
   delete a frame.  (d) It can require that you hit `?' again, to insert
   the `?' char (after moving back to the right frame).

   For example, `emacs -Q', then set `pop-up-frames' to t, then do `C-q
   ?'.  A frame pops up with the helpful text.  You must hit `?' again,
   for `?'  to be inserted.  But before that you must change the input
   focus back to the original frame, or else you will get a read-only
   error for trying to insert `?' into the *Char Help* frame.  And of
   course at some point you must manually delete that helpful frame.

6. This help enhancement appeared already in previous Emacs versions, at
   least as far back as Emacs 22.  But there, most of the behavior
   described above does not occur.  So this is a regression wrt those
   versions.  But even those versions that introduce this help are a
   regression wrt earlier Emacs versions that do not.

   At least Emacs 22-24.3 do not show help for `?', but only for `<f1>'.
   In Emacs 22 through 24.3, with `emacs -Q', `C-h ?' inserts `?'
   normally.  And `C-q <f1>' does not insert any char; it just displays
   the help text.  So far, so good.

   However, with non-nil `pop-up-frames' in Emacs 22-24.3, the same
   problems described above arise for `C-q <f1>', and `^@' is inserted
   (but at least without needing to change focus back to the original
   frame).  I never noticed that bug (regression) for Emacs 22-24.3,
   because I never hit `<f1>'.

In sum, this help display interferes with `C-q' behavior (user
interaction).  It should be removed altogether.  Or if you do not
agree with that, then at least:

1. `?' should be removed from the equation and handled as any other
   character (i.e., just inserted).  It should not solicit help.

2. The bugged behavior when `pop-up-frames' is non-nil (or via any other
   settings that cause the help buffer to use another frame) must be
   fixed.  `C-q <f1>' should not insert `^@', ever.  And the focus
   should remain in the original frame.  And the help buffer's frame
   should be deleted when `quoted-insert' is done.

`C-q' should not interpret ANY characters, such as `?' specially as
instructions to show help.  It should just insert the character
("quoted", per its description), as it has always done before.

Yes, `<f1>' is not a character.  It could, as before (e.g. in Emacs
22-24.3), show such help.  But it should not do so in another frame
etc., or if it must, then that temporary help frame should be deleted
after the char is inserted, i.e., when `quoted-insert' has finished its
job.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-01-23 on ODIEONE
Bzr revision: 116129 monnier <at> iro.umontreal.ca-20140123150141-qopqqhpm8jqo8a18
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Wed, 02 Apr 2014 17:12:01 GMT) Full text and rfc822 format available.

Message #8 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 16617 <at> debbugs.gnu.org
Subject: RE: bug#16617: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Wed, 2 Apr 2014 10:11:38 -0700 (PDT)
There has been no response to this regression report, which includes a clear recipe to repro it.

This problem is still present as of this build:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-30 on ODIEONE
Bzr revision: 116912 rgm <at> gnu.org-20140331004905-epgjyxkpa4nv54bm
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 11:05:02 GMT) Full text and rfc822 format available.

Message #11 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 14:04:21 +0300
Drew Adams <drew.adams <at> oracle.com> writes:

> There has been no response to this regression report, which includes a
> clear recipe to repro it.

Either the recipe is not clean, or you probably haven't tried it
starting from `emacs -Q'.

`C-q ?' and `C-q <f1>' insert ? or a non-printable character here.

No help buffers.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 13:35:03 GMT) Full text and rfc822 format available.

Message #14 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 21:34:07 +0800
On 2014-04-03 01:11 +0800, Drew Adams wrote:
> There has been no response to this regression report, which includes a clear recipe to repro it.
>
> This problem is still present as of this build:
>

Thanks for the report and sorry I missed it.

Stefan,

Can I fix it in emacs-24 along these lines? Thanks.   - Leo

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2014-04-02 15:14:50 +0000
+++ lisp/simple.el	2014-04-03 13:31:12 +0000
@@ -658,11 +658,17 @@
 The optional argument PROMPT specifies a string to use to prompt the user.
 The variable `read-quoted-char-radix' controls which radix to use
 for numeric input."
-  (let ((message-log-max nil) done (first t) (code 0) translated)
+  (let ((message-log-max nil)
+	(help-events (delq nil (mapcar (lambda (c) (unless (characterp c) c))
+				       help-event-list)))
+	done (first t) (code 0) translated)
     (while (not done)
       (let ((inhibit-quit first)
-	    ;; Don't let C-h get the help message--only help function keys.
+	    ;; Don't let C-h or other help chars get the help
+	    ;; message--only help function keys. See bug#16617.
 	    (help-char nil)
+	    (help-event-list help-events)
 	    (help-form
 	     "Type the special character you want to use,
 or the octal character code.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 14:33:01 GMT) Full text and rfc822 format available.

Message #17 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 16617 <at> debbugs.gnu.org
Subject: RE: bug#16617: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Thu, 3 Apr 2014 07:32:02 -0700 (PDT)
> > There has been no response to this regression report, which includes a
> > clear recipe to repro it.
> 
> Either the recipe is not clean, or you probably haven't tried it
> starting from `emacs -Q'.
> 
> `C-q ?' and `C-q <f1>' insert ? or a non-printable character here.
> No help buffers.

It seems that you did not read the bug report well.  Did you see this
part?

 4. With `emacs -Q', you might not even notice the popped-up *Char Help*
    buffer, which means that it does not even do what the enhancer
    presumably intended.  It just flashes for an instant - impossible to
    read it, and serving no purpose but to annoy and puzzle.  This alone
    is a regression wrt previous Emacs releases.

Do I need to make the recipe clearer?

emacs -Q
M-x set-variable pop-up-frames t
In a writable buffer: C-q ?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 15:15:03 GMT) Full text and rfc822 format available.

Message #20 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 16617 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 18:14:30 +0300
> From: Leo Liu <sdl.web <at> gmail.com>
> Date: Thu, 03 Apr 2014 21:34:07 +0800
> Cc: 16617 <at> debbugs.gnu.org
> 
> On 2014-04-03 01:11 +0800, Drew Adams wrote:
> > There has been no response to this regression report, which includes a clear recipe to repro it.
> >
> > This problem is still present as of this build:
> >
> 
> Thanks for the report and sorry I missed it.
> 
> Stefan,
> 
> Can I fix it in emacs-24 along these lines? Thanks.   - Leo

FWIW, I don't think this is the right fix.  The problem is not that
'?' pops up the help text -- I disagree with Drew about that, as '?'
is a normal way to ask Emacs for guidance.  The problem is that the
help text is not really displayed -- it flashes for a fraction of a
second and disappears without a trace.  Your suggestion doesn't fix
that part.  Even if it is eventually decided that '?' should not
invoke help in this case, the problem with momentarily flashing the
help text should be solved, because it actually renders the whole
help-form feature useless.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 15:17:02 GMT) Full text and rfc822 format available.

Message #23 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16617 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 18:16:43 +0300
> Date: Thu, 3 Apr 2014 07:32:02 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 16617 <at> debbugs.gnu.org
> 
> > > There has been no response to this regression report, which includes a
> > > clear recipe to repro it.
> > 
> > Either the recipe is not clean, or you probably haven't tried it
> > starting from `emacs -Q'.
> > 
> > `C-q ?' and `C-q <f1>' insert ? or a non-printable character here.
> > No help buffers.
> 
> It seems that you did not read the bug report well.  Did you see this
> part?
> 
>  4. With `emacs -Q', you might not even notice the popped-up *Char Help*
>     buffer, which means that it does not even do what the enhancer
>     presumably intended.  It just flashes for an instant - impossible to
>     read it, and serving no purpose but to annoy and puzzle.  This alone
>     is a regression wrt previous Emacs releases.

I think it flashes so quickly that is impossible to notice on some
platforms or configurations.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 15:24:02 GMT) Full text and rfc822 format available.

Message #26 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;	REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Thu, 03 Apr 2014 18:23:42 +0300
On 03.04.2014 18:16, Eli Zaretskii wrote:

> I think it flashes so quickly that is impossible to notice on some
> platforms or configurations.

I can only notice it if I open two windows with the same buffer (in 
which I press C-q ?).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 15:40:05 GMT) Full text and rfc822 format available.

Message #29 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 23:39:08 +0800
On 2014-04-03 23:14 +0800, Eli Zaretskii wrote:
> FWIW, I don't think this is the right fix.  The problem is not that
> '?' pops up the help text -- I disagree with Drew about that, as '?'
> is a normal way to ask Emacs for guidance.  The problem is that the
> help text is not really displayed -- it flashes for a fraction of a
> second and disappears without a trace.  Your suggestion doesn't fix
> that part.  Even if it is eventually decided that '?' should not
> invoke help in this case, the problem with momentarily flashing the
> help text should be solved, because it actually renders the whole
> help-form feature useless.

Agreed.

Leo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 15:51:01 GMT) Full text and rfc822 format available.

Message #32 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 18:51:07 +0300
> From:  Leo Liu <sdl.web <at> gmail.com>
> Cc: 16617 <at> debbugs.gnu.org
> Date: Thu, 03 Apr 2014 23:39:08 +0800
> 
> On 2014-04-03 23:14 +0800, Eli Zaretskii wrote:
> > FWIW, I don't think this is the right fix.  The problem is not that
> > '?' pops up the help text -- I disagree with Drew about that, as '?'
> > is a normal way to ask Emacs for guidance.  The problem is that the
> > help text is not really displayed -- it flashes for a fraction of a
> > second and disappears without a trace.  Your suggestion doesn't fix
> > that part.  Even if it is eventually decided that '?' should not
> > invoke help in this case, the problem with momentarily flashing the
> > help text should be solved, because it actually renders the whole
> > help-form feature useless.
> 
> Agreed.

To help investigating this, I can say that it looks like we call
help-form-show, which displays the help text inside
with-output-to-temp-buffer, and when help-form-show returns, we call
read_char, which calls redisplay.  But since
with-output-to-temp-buffer already exited by that time, redisplay
simply pops down the help buffer, so the user doesn't get the chance
to read the text.  Moreover, the help character, either '?' or F1,
gets inserted into the original buffer, instead of being gobbled by
the code which pops up the help text.

Hope this description will help someone fix the feature.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 16:25:02 GMT) Full text and rfc822 format available.

Message #35 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16617 <at> debbugs.gnu.org
Subject: Re: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 19:24:15 +0300
> Date: Sat, 1 Feb 2014 11:15:45 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> This is a regression.  `C-q ?' pops up an annoying "*Char Help*" buffer.

This is indeed a regression, but the only real bug I see here is that
the "*Char Help*" buffer pops _down_ so quickly one can hardly notice
it, let alone read the text it wants to display.

> What is said here for `?' is also true for `<f1>'.  It is not true for
> `C-h', however.

C-h is explicitly excluded from triggering this.  I don't know why '?'
should also be excluded -- it's not like someone needs C-q to insert
'?' in most situations -- but in any case it's one of the help
characters, and many commands show help when user presses '?'.  I
don't see why this command should not.

> The char inserted when using `C-q <f1>' is `^@'.
> `<f1>' is not a character, so it should not cause a character to be
> inserted.

I disagree.  C-q causes the next keystroke act as self-inserting
character.  What that inserts depends on the keyboard configuration
and on the platform.  I don't know how you decided that F1 should not
cause any insertions; FWIW, Emacs inserts ^@ (i.e. null) on GNU/Linux
as well, at least on the system where I tried.

> 1. The text in this help buffer is not formatted (e.g. filled)
>    correctly.

Not sure if that is on purpose, but I can see some logic to the way it
is shaped.

> 2. The doc string for `quoted-insert' does not even mention this bizarre
>    `?' behavior.

'?' is a usual help character; we don't mention its effect in any
other commands, so why should this be different?

>    Nor does this behavior seem to be documented elsewhere.

??? From the Emacs manual (node "Help"):

     `C-h', <F1>, or `?' means "help" in various other contexts as well.
  For instance, you can type them after a prefix key to view a list of
  the keys that can follow the prefix key.  (A few prefix keys don't
  support `C-h' or `?' in this way, because they define other meanings
  for it, but they all support <F1> for help.)

>    It is not even listed in NEWS as a change (an incompatible change, no
>    less).

This feature is very old, so I don't see why you'd want to find it in
NEWS.  We don't usually announce regressions in NEWS.

> 3. This *Char Help* buffer should not be popped up at all - for ANY char
>    that you type after `C-q'.  This is a misfeature.  `?' should just be
>    inserted, with no noise.  It should certainly not be interpreted as
>    a plea for help.

Disagree, see above.  C-q is just another command, and as such, it can
benefit from some user guidance, like other commands.

> 4. With `emacs -Q', you might not even notice the popped-up *Char Help*
>    buffer, which means that it does not even do what the enhancer
>    presumably intended.  It just flashes for an instant - impossible to
>    read it, and serving no purpose but to annoy and puzzle.  This alone
>    is a regression wrt previous Emacs releases.

Agreed.  This should be fixed.

> 5. In other contexts it can be even more annoying: (a) The help really
>    is shown.  (b) It can remain shown, requiring the user to remove it.
>    (c) That can even involve requiring the user to change buffers and
>    delete a frame.  (d) It can require that you hit `?' again, to insert
>    the `?' char (after moving back to the right frame).

This isn't different from any other help, is it?  If so, I see no
problem here, just the usual Emacs behavior.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 18:39:03 GMT) Full text and rfc822 format available.

Message #38 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Leo Liu <sdl.web <at> gmail.com>
Cc: 16617 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: RE: bug#16617: 24.3.50;	REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Thu, 3 Apr 2014 11:38:15 -0700 (PDT)
> FWIW, I don't think this is the right fix.  The problem is not that
> '?' pops up the help text -- I disagree with Drew about that, as '?'
> is a normal way to ask Emacs for guidance.  The problem is that the
> help text is not really displayed -- it flashes for a fraction of a
> second and disappears without a trace.  Your suggestion doesn't fix
> that part.  Even if it is eventually decided that '?' should not
> invoke help in this case, the problem with momentarily flashing the
> help text should be solved, because it actually renders the whole
> help-form feature useless.

No, what you describe is one problem - a problem for the
`pop-up-frames' = nil case (or equivalent).  But that is not the
problem that concerns my context, which I care about at least as
much as the `pop-up-frames' = nil case.

The only problem you are apparently concerned about is the one
I referred to as "This alone is a regression wrt previous Emacs
releases."  "This alone" means that this is one regression - an
additional regression, but it is NOT the regression that is the
main reason for my bug report.

What problem did I report?  "`C-q ?' pops up an annoying
"*Char Help*" buffer."  What part of that is not clear?

It is true that I also I reported, in passing, some additional
problems - problems with that annoying help display.  See the
original report.  They include minor ones such as <f1> inserting
a character and lack of formatting (filling) in the help buffer.

For my case (non-nil `pop-up-frames'), the major annoyance about
the help buffer display is this:

 "(b) It can remain shown, requiring the user to remove it.
  (c) That can even involve requiring the user to change buffers
      and delete a frame.
  (d) It can require that you hit `?' again, to insert the `?'
      char (after moving back to the right frame)."

But again, NONE of that is the real bug that this report is about.
THIS bug has nothing to do with these particular negative
qualities of the help display as implemented.  THIS bug is
that the help display is shown at all!  (See the subject line.)

Why should `C-q ?' show any "help"?  Why doesn't it just insert
the character `?'?  `C-q w' inserts the character `w'.  Why
should `C-q ?' act differently?  It does some pretty weird things:

(1) It does not insert `?' (which is all that it should do).
(2) It pops up an incomprehensible (in this context) "help"
    buffer that is no help at all.  Totally inappropriate.
(3) If you try `C-h ?' again in the same buffer while *Char
    Help* is already displayed (e.g., in the separate, popped-up
    frame, which remains until the user deletes it), then buffer
    *Help* is popped up, with the content you normally see from
    `C-h C-h':

      This is the Emacs `help-command', accessible via `C-h'.
      Type a help option (below) now, for help on a particular
      topic.
      ...
      [52 lines of help]

    Also totally inappropriate.

(I did not report #3 originally - I discovered it now.  It is
just one more problem with the help-display implementation.
But again - NOT the real bug reported, which is that `C-h ?'
should not display "help" at all.)

The FIX for this bug is to treat `?' like the ordinary printable,
self-inserting character that it is in such contexts: `C-q'
should simply insert `?'.  End of story.  Hard to believe there
is so much attention paid to everything but the obvious here.

If you also want to fix the additional problems with the *Char
Help* display which I mentioned, please do.  But they have
nothing to do with THIS bug, which is that `C-h ?' should simply
insert `?', at least whenever `?' is self-inserting.

> I don't know why '?' should also be excluded

It is an ordinary, printable, self-inserting character in the
context I reported.  `<f1>' is not - it is not comparable to `?'
(or even to ^H, which `C-q' handles correctly, BTW, inserting ^H).

> -- it's not like someone needs C-q to insert '?' in most
> situations

It is not about "need".  `C-q' is SUPPOSED to insert ordinary,
self-inserting characters.  For such characters its "quoting"
is SUPPOSED to just be the identity (a no-op).  That should be
true for ALL self-inserting chars, including `?'.

> -- but in any case it's one of the help characters,

No, it is definitely not "one of the help characters".
Not in the reported context, and not in MOST buffers.

> and many commands show help when user presses '?'.  I
> don't see why this command should not.

No, when the user presses `?' in the context I reported,
no "commands show help".  Pressing `?' just inserts it.

Let me say again, in no uncertain terms, what THIS bug is about:

At least whenever `?' is self-inserting - i.e., bound to
`self-insert-command' or another command that inserts it, `C-q'
should just insert it.  A self-inserting character should not
be treated as a "help" command!

I will go further and say that UNLESS `?' is a help character
(i.e., bound to a help command), `C-q ?' should insert `?'.
So for example, if `?' is bound to `end-of-line' or
`complete-symbol', `C-q ?' should insert `?'.

I would even argue that `C-q ?' should always insert `?' - even
when it is a help character.  That's what quoting is about.
And you will note that that is what `C-q C-h' does: it inserts
the Control-H character.  Even though it is "one of the help
characters".

But I won't insist on that last degree here (for THIS bug) -
we can save that for another discussion, perhaps.  What you
say might constitute a reasonable argument in a buffer where
`?' is in fact "one of the help characters".  I don't agree
with that argument, and it conflicts with what `C-q' does for
`C-h', but it is arguable.

The point here is that that case (where `?' is a help char) is
a tiny minority of the contexts where users actually insert
characters (using `C-q' or otherwise).  In most editable
buffers, `?' just self-inserts - it is certainly not a "help
character", and at least in these (common) contexts, `C-q'
should stay out of the way.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 19:24:01 GMT) Full text and rfc822 format available.

Message #41 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16617 <at> debbugs.gnu.org, sdl.web <at> gmail.com, drew.adams <at> oracle.com
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 03 Apr 2014 22:24:00 +0300
> Date: Thu, 3 Apr 2014 11:38:15 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: drew.adams <at> oracle.com, 16617 <at> debbugs.gnu.org
> 
> What problem did I report?  "`C-q ?' pops up an annoying
> "*Char Help*" buffer."  What part of that is not clear?

It's clear, I just don't agree that it's a problem.  It is intended
behavior shared by many other Emacs commands.

> Why should `C-q ?' show any "help"?

Because '?' is a help character.

> Why doesn't it just insert the character `?'?  `C-q w' inserts the
> character `w'.  Why should `C-q ?' act differently?

For the same reason "M-x ?" triggers a different response than "M-x w".

> The FIX for this bug is to treat `?' like the ordinary printable,
> self-inserting character that it is in such contexts: `C-q'
> should simply insert `?'.  End of story.

You can say this till Kingdom Come, it won't change the basic facts:
this is a very old feature, and I at least see no reason to remove it,
since Emacs behaves like that in many other commands.  End of story.

> > I don't know why '?' should also be excluded
> 
> It is an ordinary, printable, self-inserting character in the
> context I reported.

No, it isn't.  It is a character that invokes help.

> `C-q' is SUPPOSED to insert ordinary, self-inserting characters.

And "M-x" is supposed to echo the next word, but '?' still behaves
differently there.

Just let go, Drew.  You keep repeating the same arguments, and they
didn't fly the first time.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 19:33:02 GMT) Full text and rfc822 format available.

Message #44 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Thu, 03 Apr 2014 12:32:02 -0700
[Message part 1 (text/plain, inline)]
Drew's right this time.

On 04/03/2014 12:24 PM, Eli Zaretskii wrote:
>> Date: Thu, 3 Apr 2014 11:38:15 -0700 (PDT)
>> From: Drew Adams <drew.adams <at> oracle.com>
>> Cc: drew.adams <at> oracle.com, 16617 <at> debbugs.gnu.org
>>
>> What problem did I report?  "`C-q ?' pops up an annoying
>> "*Char Help*" buffer."  What part of that is not clear?
> 
> It's clear, I just don't agree that it's a problem.  It is intended
> behavior shared by many other Emacs commands.
> 
>> Why should `C-q ?' show any "help"?
> 
> Because '?' is a help character.

We should make an exception for C-q. Its purpose is explicitly to
*override* normal Emacs convention. I'd be happy echoing a help message
as soon as C-q is entered, and maybe popping up help on F1, but we
should certainly treat "?" like any other character.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 03 Apr 2014 20:59:02 GMT) Full text and rfc822 format available.

Message #47 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: RE: bug#16617: 24.3.50;	REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Thu, 3 Apr 2014 13:58:25 -0700 (PDT)
> It's clear, I just don't agree that it's a problem.  It is intended
> behavior shared by many other Emacs commands.
> 
> > Why should `C-q ?' show any "help"?
>
> Because '?' is a help character.

1. Not in most contexts, it is not.  Did you type your reply message in
   Emacs?  When you typed `?', did Emacs pop up a help buffer?  If not,
   do you wish it had?

2. And `C-h' IS a help character in most contexts.  And yet `C-q C-h'
   inserts a Control-Q character - it does NOT pop up a help buffer.
   So the argument that help characters must behave the way you claim
   just does not hold water.

> > Why doesn't it just insert the character `?'?  `C-q w' inserts the
> > character `w'.  Why should `C-q ?' act differently?
> 
> For the same reason "M-x ?" triggers a different response than "M-x w".

3. `?' is specifically bound to a help command, `minibuffer-completion-help',
   in `minibuffer-local-must-match-map'.  It is not bound to a help char
   in the recipe I gave (e.g. in *scratch*).

4. And I specifically stated that THIS bug report is NOT for the cases
   where `?' is bound to a help command.  Even though the same arguments
   hold for that rare case as well, I will not include it as part of this
   bug report.  I'm willing to limit THIS bug report to the vast majority
   of cases: those in which `?' is NOT bound to a help character.

> You can say this till Kingdom Come, it won't change the basic facts:
> this is a very old feature,

It is still a regression wrt even older behavior. 

> and I at least see no reason to remove it,

Too bad.

> since Emacs behaves like that in many other commands.

Name one.  What is similar to this?

> End of story.
> 
> > > I don't know why '?' should also be excluded
> >
> > It is an ordinary, printable, self-inserting character in the
> > context I reported.
> 
> No, it isn't.  It is a character that invokes help.

No, it is NOT.  Not in the contexts that THIS bug report is about.

emacs -Q
In *scratch*: `C-q ?'

`?' is not a character that invokes help in *scratch*.  Likewise
in most buffers/modes.

You try to distract us by giving an example of `?' in
`minibuffer-local-must-match-map', where it IS a help character.
That's a shame.

And even there, I would argue (but not for this bug report) that
`C-q ?' should just insert `?'.

> > `C-q' is SUPPOSED to insert ordinary, self-inserting characters.
> 
> And "M-x" is supposed to echo the next word, but '?' still behaves
> differently there.

No, again a strawman.  M-x does lots of things.  And `?' is not a
word-constituent in the minibuffer for M-x.  It is not even
self-inserting.  It is 100% irrelevant to THIS bug.

(Oh and BTW, IMO `?' *should* be self-inserting in the minibuffer.)

> Just let go, Drew.  You keep repeating the same arguments, and they
> didn't fly the first time.

Ditto.  But I would suggest that you think a little more about this.

Do I really care?  Not so much, except in so far as I care about
Emacs.  I probably came across this bug by accidentally hitting
`C-q ?' instead of `C-q C-?' or something - I really don't recall.

As you point out, this has been broken for a long time.  And I only
recently noticed it.  It doesn't bother me if you leave this broken
forever.  That would be too bad for Emacs (unclean), but I wouldn't
lose any sleep over it.  Have a nice day.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Fri, 04 Apr 2014 07:44:02 GMT) Full text and rfc822 format available.

Message #50 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 16617 <at> debbugs.gnu.org, sdl.web <at> gmail.com, drew.adams <at> oracle.com
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Fri, 04 Apr 2014 10:44:00 +0300
> Date: Thu, 03 Apr 2014 12:32:02 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
> 
> Drew's right this time.

In what part(s) of his long list of complaints?

> >> Why should `C-q ?' show any "help"?
> > 
> > Because '?' is a help character.
> 
> We should make an exception for C-q. Its purpose is explicitly to
> *override* normal Emacs convention. I'd be happy echoing a help message
> as soon as C-q is entered, and maybe popping up help on F1, but we
> should certainly treat "?" like any other character.

Not sure I agree about '?', but in any case this is NOT the main part
of Drew's complaints.  He says that help text should not be shown at
all, ever.  _That_ is certainly not a regression, as Emacs have
behaved like that since about forever.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Fri, 04 Apr 2014 08:03:02 GMT) Full text and rfc822 format available.

Message #53 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Fri, 04 Apr 2014 11:02:29 +0300
> Date: Thu, 3 Apr 2014 13:58:25 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
> 
> Have a nice day.

I will, thank you.

To reiterate, the only regression in this regard is this:

  C-q F1

In previous versions of Emacs, this would pop up a buffer explaining
what C-q expects and what it does.  In the current emacs-24 branch and
the trunk, it momentarily flashes that buffer, and then inserts a null
character, instead of waiting for another key and inserting that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Fri, 04 Apr 2014 16:26:01 GMT) Full text and rfc822 format available.

Message #56 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Daniel Colascione <dancol <at> dancol.org>
Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: RE: bug#16617: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Fri, 4 Apr 2014 09:25:19 -0700 (PDT)
> Not sure I agree about '?', but in any case this is NOT the main part
> of Drew's complaints.  He says that help text should not be shown at
> all, ever.

No, I did NOT say that at all.  You seem to have trouble reading the
bug report.  I said that THIS bug is ONLY that the help text is shown
for `?' in contexts where `?' is not a help character.

It's about `?'.  And NOT about all contexts.  And certainly NOT about
no help text "at all, ever".  Those are strawman misrepresentations
of this bug report.

You complain that I repeat myself, but you don't seem to be able to
read what is before your eyes, whether the first time or the Nth time.
Yes, evidently repeating and rephrasing has not helped.  What else
can I do to get you to not misread or misrepresent what I have said
so clearly and explicitly?

I specifically EXCLUDED the case where `?' is a help character from
THIS bug report, even though my personal opinion is that also in
that case, yes, `C-q' should quote it.  Just as it does for `C-h',
when it is a help char (which is most of the time).

Why you would insist upon a different behavior for `C-q ?' versus
`C-q C-h', in contexts where `?' and `C-h' are help chars, is
beyond me.

But asking for the former to be treated like the latter in such
contexts is explicitly NOT part of THIS bug report.  This one is
only about restoring `C-q ?' to quoting when `?' is NOT a help char.

How to get this across to you?  Or do you perhaps hear that message
clearly but stubbornly refuse to acknowledge it, choosing instead
to reject an imaginary, strawman report (Drew "says that help text
should not be shown at all, ever")?

If I really thought, as you claim, that such help text should never
be shown, why would I bother to point out specific problems with
the implementation of that help-text display (e.g., flash/no-see for
nil `pop-up-frames'; non-removal of separate frame for non-nil
`pop-up-frames')?

Those observances are to help you IMPROVE the implementation of
that help-text display.  It is clearly not something that I reject
in general.  But THIS bug is only about that display being
inappropriate in certain contexts (most contexts, as it turns out).
I mentioned such help-text display problems only in passing - you
can ignore them for THIS bug.

> _That_ is certainly not a regression, as Emacs have
> behaved like that since about forever.

I also doubt that that is true.  Certainly in Emacs 20 `C-q ?'
inserts `?' when `?' is not a help char.  IOW, THIS regression is
not present in Emacs 20.

And I don't know a mode to test (e.g. for Emacs 20) whether
`C-q ?' also inserts `?' when `?' is a help char AND the mode is
not read-only.  Do you?

And `grep' does not find "Char Help" anywhere in the Emacs 20 lisp
or C files.

So it's not clear to me that in Emacs 20 `C-q ?' ever shows
"that help text".  Or any help text.  So even beyond THIS
regression, my guess is that NONE of the problems I mentioned
are present in Emacs 20.

The same might even be true for Emacs 21, but I don't have that
version anymore, to test.  As I said in the original bug report,
this regression goes back to at least Emacs 22.  It does not go
back to Emacs 20, and certainly not "about forever".

And it is so unlikely that someone would stumble upon this bug
that I am not surprised if this has not been reported before,
even if the regression has been present since Emacs 22.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Fri, 04 Apr 2014 19:44:01 GMT) Full text and rfc822 format available.

Message #59 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: dancol <at> dancol.org, sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Fri, 04 Apr 2014 22:43:40 +0300
> Date: Fri, 4 Apr 2014 09:25:19 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
> 
> > Not sure I agree about '?', but in any case this is NOT the main part
> > of Drew's complaints.  He says that help text should not be shown at
> > all, ever.
> 
> No, I did NOT say that at all.  You seem to have trouble reading the
> bug report.  I said that THIS bug is ONLY that the help text is shown
> for `?' in contexts where `?' is not a help character.

Ts-ts-ts, and I was having such a good day until now...  Oh, well...

Drew in his original report:

> 3. This *Char Help* buffer should not be popped up at all - for ANY char
>    that you type after `C-q'.  This is a misfeature.

(Of course now you will claim that F1 is not a character.)

> > _That_ is certainly not a regression, as Emacs have
> > behaved like that since about forever.
> 
> I also doubt that that is true.  Certainly in Emacs 20 `C-q ?'
> inserts `?' when `?' is not a help char.  IOW, THIS regression is
> not present in Emacs 20.

Try with F1.

> And `grep' does not find "Char Help" anywhere in the Emacs 20 lisp
> or C files.

It was just *Help* back then.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Fri, 04 Apr 2014 20:21:01 GMT) Full text and rfc822 format available.

Message #62 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dancol <at> dancol.org, sdl.web <at> gmail.com, 16617 <at> debbugs.gnu.org
Subject: RE: bug#16617: 24.3.50; REGRESSION: `C-q ?' pops up annoying *Char
 Help* buffer
Date: Fri, 4 Apr 2014 13:20:32 -0700 (PDT)
> > 3. This *Char Help* buffer should not be popped up at all -
> >    for ANY char that you type after `C-q'.  This is a
> >    misfeature.
> 
> (Of course now you will claim that F1 is not a character.)

You can take anything you want out of context, if your aim is
to obfuscate.  I have made it clear MANY times by now that THIS
bug is about `?', and specifically when it is not bound to a
help char.

I have also said, as in the quote above, that IMO `C-q' should
quote all chars, regardless of whether they are bound to a help
char.  And I pointed out that this is already the case for
`C-q C-h' (to which you have nothing to say, apparently).  But
I have clearly insisted that THIS bug is not about fixing that
more general problem too.  I said that we can discuss that
separately, if you like.

(And yes, I also pointed out from the outset - not just "now" -
that F1 is not a char.)

Even the subject line summarizes this bug fairly well.  The
only thing it does not do is distinguish (e.g., exclude) the
tiny minority of cases where `?' is a help char.  It clearly
does not say that `C-q' must quote all chars.

And again, `C-q' DOES quote the help char `C-h'.  Based on your
silence about `C-h' and your argument that `?' should not be
quoted BECAUSE it is a help char (which it is only rarely, BTW),
you seem to claim that `C-q' should quote some help chars but
not others.  Maybe you would like to clarify that?

> > > _That_ is certainly not a regression, as Emacs have
> > > behaved like that since about forever.
> >
> > I also doubt that that is true.  Certainly in Emacs 20 `C-q ?'
> > inserts `?' when `?' is not a help char.  IOW, THIS regression is
> > not present in Emacs 20.
> 
> Try with F1.

Again, "THIS regression".  Search for "THIS" in the thread and you
will find that I've been very clear that THIS bug is about `?'.
 
> > And `grep' does not find "Char Help" anywhere in the Emacs 20
> > lisp or C files.
> 
> It was just *Help* back then.

OK, I see that.  But again, `C-q ?' does not show the help, in
*Help* or anywhere else.  THIS bug is a clear regression wrt
Emacs 20.  And, as mentioned, also wrt Emacs 22 through 24.3.
For none of those releases does `C-q ?' show help.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Sun, 06 Apr 2014 19:34:01 GMT) Full text and rfc822 format available.

Message #65 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16617 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Sun, 06 Apr 2014 15:33:11 -0400
> This is indeed a regression, but the only real bug I see here is that
> the "*Char Help*" buffer pops _down_ so quickly one can hardly notice
> it, let alone read the text it wants to display.

No, it's very important for C-q ? to insert a ?.
This is needed in those contexts where... ? brings up a *help* buffer ;-)


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Mon, 07 Apr 2014 02:44:01 GMT) Full text and rfc822 format available.

Message #68 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 16617 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Mon, 07 Apr 2014 05:43:38 +0300
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 16617 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2014 15:33:11 -0400
> 
> > This is indeed a regression, but the only real bug I see here is that
> > the "*Char Help*" buffer pops _down_ so quickly one can hardly notice
> > it, let alone read the text it wants to display.
> 
> No, it's very important for C-q ? to insert a ?.
> This is needed in those contexts where... ? brings up a *help* buffer ;-)

Leo suggested a patch for that.




Forcibly Merged 16617 17371. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 29 Apr 2014 14:58:03 GMT) Full text and rfc822 format available.

Severity set to 'minor' from 'normal' Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 29 Apr 2014 15:19:02 GMT) Full text and rfc822 format available.

Merged 16617 17371. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 29 Apr 2014 15:19:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16617; Package emacs. (Thu, 19 Jun 2014 15:44:03 GMT) Full text and rfc822 format available.

Message #77 received at 16617 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 16617 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Thu, 19 Jun 2014 11:43:20 -0400
> Can I fix it in emacs-24 along these lines? Thanks.   - Leo

Yes, please.


        Stefan


> === modified file 'lisp/simple.el'
> --- lisp/simple.el	2014-04-02 15:14:50 +0000
> +++ lisp/simple.el	2014-04-03 13:31:12 +0000
> @@ -658,11 +658,17 @@
>  The optional argument PROMPT specifies a string to use to prompt the user.
>  The variable `read-quoted-char-radix' controls which radix to use
>  for numeric input."
> -  (let ((message-log-max nil) done (first t) (code 0) translated)
> +  (let ((message-log-max nil)
> +	(help-events (delq nil (mapcar (lambda (c) (unless (characterp c) c))
> +				       help-event-list)))
> +	done (first t) (code 0) translated)
>      (while (not done)
>        (let ((inhibit-quit first)
> -	    ;; Don't let C-h get the help message--only help function keys.
> +	    ;; Don't let C-h or other help chars get the help
> +	    ;; message--only help function keys. See bug#16617.
>  	    (help-char nil)
> +	    (help-event-list help-events)
>  	    (help-form
>  	     "Type the special character you want to use,
>  or the octal character code.








Reply sent to Leo Liu <sdl.web <at> gmail.com>:
You have taken responsibility. (Fri, 20 Jun 2014 00:17:02 GMT) Full text and rfc822 format available.

Notification sent to Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer. (Fri, 20 Jun 2014 00:17:03 GMT) Full text and rfc822 format available.

Message #82 received at 16617-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Drew Adams <drew.adams <at> oracle.com>, 16617-done <at> debbugs.gnu.org
Subject: Re: bug#16617: 24.3.50;
 REGRESSION: `C-q ?' pops up annoying *Char Help* buffer
Date: Fri, 20 Jun 2014 08:16:42 +0800
Fixed in 24.4.

On 2014-06-19 11:43 -0400, Stefan Monnier wrote:
>> Can I fix it in emacs-24 along these lines? Thanks.   - Leo
>
> Yes, please.

Done.

Leo




Reply sent to Leo Liu <sdl.web <at> gmail.com>:
You have taken responsibility. (Fri, 20 Jun 2014 00:17:03 GMT) Full text and rfc822 format available.

Notification sent to Dani Moncayo <dmoncayo <at> gmail.com>:
bug acknowledged by developer. (Fri, 20 Jun 2014 00:17:04 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 18 Jul 2014 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 306 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.