bug#11482: 24.0.96; Keep `M-s' as a prefix key for search (conflict with Gnus)

[Drew Adams]

> > I don't think there is a problem. :-) But Icicles is a minor mode that
> > binds that key globally, so there's a collision... But...
> 
> If it's not against convention, then I think Gnus can bind what it wants
> while I'm reading mail with it.

Depends on what you call "convention".  As the original bug report says:

 My understanding was that `M-s' is now pretty much reserved as a prefix
 key for search.

Isn't that the case?  Is that a convention?

 For example: `M-s w' and the Dired search keys, which all use prefix
 key `M-s f'.  My thinking for defining `M-s M-s' as an Icicles search
 prefix key was (a) `M-s' is a prefix key for Emacs search generally, and
 (b) I did not find any conflicts for `M-s M-s' on the `M-s' prefix key.
 
 But if Gnus binds `M-s' to a command, that conflicts with the general
 use of `M-s' as a prefix key (for search).  That is the bug: Gnus should
 not bind `M-s' to a command.  `M-s' should remain a prefix key (for
 search).
 
 Presumably, in the context where `M-s' is bound to a Gnus command it is
 unavailable for use by Isearch etc.  Even for Gnus users of vanilla
 Emacs, I would think that this would be a loss.

Michael Heerdegen replied that for that particular Gnus buffer there
is _not_ much use for search, and that Gnus anyway provides its own
search search command (on another key, I guess):

 That Gnus shadows the global M-s binding is another issue.  But since
 Gnus replaces it with a search command suitable for searching articles,
 it's IMHO not really a problem.  AFAIK, only the summary buffer is
 affected by the M-s binding, and there, "normal" searching is rarely
 needed.

It is true that prefix key `M-s' is _not_ called out in (elisp)
`Key Binding Conventions' as being reserved.  So in that sense it
is perhaps not a convention.  Or else that doc is not up-to-date.

There are regularities in Emacs default key bindings, which are
not called out in (elisp) `Key Binding Conventions' as being
"conventional" in the sense of being reserved.  Presumably these
regularities are only nice-to-haves, not required.

If so, the question here is whether, how much, and where Emacs
itself wants to respect such a regularity/convention.

("Emacs itself" presumably includes Gnus now, even if it might not
have back in the "mid-80s" (or '88, when Gnus was written - and no,
I do not see `M-s' there: http://www.gnus.org/2.0/gnus.el.))

So:

1. Yes, of course "Gnus can bind what it wants while [you're]
   reading mail with it."

2. A minor mode (such as Icicles) can also bind what it wants.

3. That particular Gnus buffer apparently has little need for
   search, and even less need for Isearch (`M-s ...'), as it has
   its own search command.

4. Users will generally expect `M-s' to be a search prefix key.
   That's the "convention".  It can confuse users for this or that
   mode or library to bind `M-s' to something else.  But confusion
   is not the end of the world.  And modes and libraries can have
   good reasons for bindings they make.

5. At least for Icicles, it is trivial for a user to bind Icicles
   search commands to a different prefix key from `M-s'.  This is
   really not about Icicles, IMO.

6. Because of the `M-s' "convention" and user expectations of it,
   a natural question is this: Is there a good reason for Gnus
   _not_ to use a different key from `M-s'?  I haven't seen _any_
   reason given, so far.  But again, see #1...

Feel free to close this bug, if you don't care that Gnus respects
the `M-s' "convention" and #1 is most important.  I filed the bug
report based on an Icicles user report.  I filed it because of my
understanding that `M-s' is conventionally a search prefix key.

Although it is trivial for an Icicles user to change the Icicles
prefix key for search commands from `M-s M-s' to something else,
the reporting user chose to instead change the Gnus key from `M-s'.
Maybe that says something about users expecting or wanting `M-s'
to continue to be for search.  Or maybe not - that's only one user.