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

[Drew Adams]

> 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.