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

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

[Drew Adams]

An Icicles user just brought to my attention the fact that Gnus binds
`M-s' to a command (`gnus-summary-search-article-forward', IIUC).
 
This conflicts with a default Icicles setting, but that's no big deal
because it is easy for users to customize this.  By default, Icicles
uses `M-s M-s' as a prefix key for Icicles search.
 
My understanding was that `M-s' is now pretty much reserved as a prefix
key for search.  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.
 

In GNU Emacs 24.0.96.1 (i386-mingw-nt5.1.2600)
 of 2012-04-28 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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

[Juri Linkov]

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

Gnus could bind `gnus-summary-search-article-forward' to `M-s M-s'.
It is still easy to type.

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

[Drew Adams]

> > 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).
> 
> Gnus could bind `gnus-summary-search-article-forward' to `M-s M-s'.
> It is still easy to type.

Obviously not what I was hoping for, since, as I say, Icicles uses `M-s M-s' as
a prefix key for all of its many (Icicles) search commands.

But it does satisfy the bug report, at least: it does not make `M-s' a simple
command binding.

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

[Juri Linkov]

>> > 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).
>>
>> Gnus could bind `gnus-summary-search-article-forward' to `M-s M-s'.
>> It is still easy to type.
>
> Obviously not what I was hoping for, since, as I say, Icicles uses `M-s M-s' as
> a prefix key for all of its many (Icicles) search commands.

For Icicles you could use a key prefix with Icicles specific mnemonics like
`M-s I'.

> But it does satisfy the bug report, at least: it does not make `M-s' a simple
> command binding.

There are more currently conflicting modes listed in admin/FOR-RELEASE:

  ** Check for modes which bind M-s that conflicts with a new global binding M-s
  and change key bindings where necessary.  The current list of modes:

  1. Gnus binds `M-s' to `gnus-summary-search-article-forward'.

  2. Minibuffer binds `M-s' to `next-matching-history-element'
     (not useful any more since C-s can now search in the history).

  3. `center-line' in Text mode was already moved to the text formatting
     keymap as `M-o M-s' (thus this binding is not necessary any more
     in `nroff-mode-map' too and can be removed now from the nroff mode
     because it can now use the global key binding `M-o M-s' `center-line').

  4. PCL-CVS binds `M-s' to `cvs-status', and log-edit-mode binds it to
     `log-edit-comment-search-forward'.  Perhaps search commands
     on the global key binding `M-s' are useless in these modes.

  5. Rmail binds `\es' to `rmail-search'/`rmail-summary-search'.

(If this problem is not release-critical then it should be removed from
admin/FOR-RELEASE.  It is recorded now here in bug#11482.)

Like the proposed keybinding `M-s M-s' for Gnus, the minibuffer could
rebind `next-matching-history-element' to `M-s M-s'.  And perhaps Shell
could bind `comint-history-isearch-forward-regexp' to `M-s M-s' as well.

However, I have doubts about rebinding `rmail-search' to `M-s M-s'
because of the comment in rmail.el:

    ;; I find I can't live without the default M-r command -- rms.

Does this statement apply to `M-s' too?

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

[Drew Adams]

> >> Gnus could bind `gnus-summary-search-article-forward' to `M-s M-s'.
> >> It is still easy to type.
> >
> > Obviously not what I was hoping for, since, as I say, 
> > Icicles uses `M-s M-s' as a prefix key for all of its many
> > (Icicles) search commands.
> 
> For Icicles you could use a key prefix with Icicles specific 
> mnemonics like `M-s I'.

Certainly I could.  But `M-s M-s' is a _lot_ more convenient for a prefix key
than is fiddling around with first Meta then Shift (then...).  Which is why I
chose it.  As I said, there are a lot of Icicles search keys on that prefix.
Here's a taste:

M-s M-s C-l     icicle-search-pages
M-s M-s ,       icicle-tags-search
M-s M-s D       icicle-search-defs-full
M-s M-s I       icicle-imenu-full
M-s M-s J       icicle-search-bookmarks-together
M-s M-s O       icicle-search-overlay-property
M-s M-s T       icicle-search-text-property
M-s M-s X       icicle-search-xml-element-text-node
M-s M-s b       icicle-search-buffer
M-s M-s c       icicle-search-char-property
M-s M-s d       icicle-search-defs
M-s M-s f       icicle-search-file
M-s M-s i       icicle-imenu
M-s M-s j       icicle-search-bookmark
M-s M-s k       icicle-search-keywords
M-s M-s l       icicle-search-lines
M-s M-s o       icicle-occur
M-s M-s p       icicle-search-paragraphs
M-s M-s s       icicle-search-sentences
M-s M-s t       icicle-search-thing
M-s M-s w       icicle-search-word
M-s M-s x       icicle-search-xml-element
M-s M-s M-s     icicle-search-generic

Plus `M-s M-s m', which is a mode-specific Icicles search.  For example, in
Dired mode it searches the marked files, including those (marked in other Dired
buffers) in the marked subdirs, recursively.  In the `*Bookmark List*' it
searches the targets of the marked bookmarks.  In Ibuffer mode it searches the
marked buffers.  And so on.

That's a pretty good use of `M-s M-s' as a prefix key, I think.  IOW, there are
not just one or two keys on the prefix.

And Icicles was first! ;-)  Certainly there is nothing special about Gnus, that
it should get awarded the `M-s M-s' prize...

Anyway, I'd probably sooner keep `M-s M-s' as the default value of the prefix
key for Icicles users.  As I said, it's very easy for a user to customize the
existing option to change the prefix key if need be.  And it's not clear that
most Icicles users will use Gnus anyway. ;-)

> > But it does satisfy the bug report, at least: it does not 
> > make `M-s' a simple command binding.
> 
> There are more currently conflicting modes listed in 
> admin/FOR-RELEASE:
> 
>   ** Check for modes which bind M-s that conflicts with a new 
>      global binding M-s and change key bindings where necessary.
>      The current list of modes:
> 
>   2. Minibuffer binds `M-s' to `next-matching-history-element'
>      (not useful any more since C-s can now search in the history).

I don't see #2 as a problem at all.  We're talking top-level bindings, or should
be.  The only possible conflict for #2 is wrt Isearch in the minibuffer.  I
don't think that should be a criterion here.

The others you mention are all conflicts of the same sort as Gnus, and should,
IMO, be changed from `M-s' to something else.

> Like the proposed keybinding `M-s M-s' for Gnus,

Which I am not in favor of...  I mention it as an existing conflict and suddenly
it's a proposal for Gnus?

> the minibuffer could rebind `next-matching-history-element'
> to `M-s M-s'. 

There is no need to rebind the minibuffer's current use of `M-s', IMO.

> And perhaps Shell could bind `comint-history-isearch-forward-regexp' to `M-s 
> M-s' as well.

So now you want to completely appropriate the key I complained about Gnus
conflicting with, creating even more conflicts for Icicles?  Gee, thanks.

I suppose I should take comfort in the adage that imitation is a form of
flattery.  But I would prefer that Emacs just leave `M-s M-s' well enough alone.

> However, I have doubts about rebinding `rmail-search' to `M-s M-s'...

I suggest to leave `M-s M-s' alone - no default binding, and just take care of
this bug, which is about NOT binding commands to `M-s', now that it is a prefix
key for search.

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

[Drew Adams]

> And Icicles was first! ;-)  Certainly there is nothing 
> special about Gnus, that it should get awarded the `M-s M-s' prize...
> 
> Anyway, I'd probably sooner keep `M-s M-s' as the default 
> value of the prefix key for Icicles users.  As I said, it's very
> easy for a user to customize the existing option to change the
> prefix key if need be.  And it's not clear that
> most Icicles users will use Gnus anyway. ;-)

FWIW, I might mention too that the Icicles + Gnus user who reported the conflict
chose to change the Gnus keybinding when I suggested he do one of the following:

>> Aside from learning about that conflict, here is how to remove
>> the conflict - you can do either of these:
>>
>> * Customize option `icicle-search-key-prefix', so that it is no
>>   longer `M-s M-s'.
>>
>> * Change the binding of `gnus-summary-search-article-forward'
>>   in `gnus-summary-mode-map' so that it is no longer `M-s'.
>
> I think I will go with the latter, although I'm not sure what
> to bind it to.  Your bug report below will hopefully alert Gnus
> developers to come up with something more sensible.

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> An Icicles user just brought to my attention the fact that Gnus binds
> `M-s' to a command (`gnus-summary-search-article-forward', IIUC).
>
> This conflicts with a default Icicles setting, but that's no big deal
> because it is easy for users to customize this.  By default, Icicles
> uses `M-s M-s' as a prefix key for Icicles search.

What are Icicles searches used for?  That is, is it likely that a user
would issue that command in the Gnus summary buffer?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Drew Adams]

> What are Icicles searches used for?  That is, is it likely that a
> user would issue that command in the Gnus summary buffer?

The same thing Isearch is used for.  Yes, I don't see why not.

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

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> What are Icicles searches used for?  That is, is it likely that a user
> would issue that command in the Gnus summary buffer?

Not being able to perform Icicle search was not the problem, it is a
problem the other way round: Icicles' binding is a minor mode binding,
thus shadowing the Gnus M-s binding, which is really important.  That's
the problem.  Without a keybinding, it is also harder to find, e.g. with
C-h b etc.  I had suggested to Lars to change the Gnuish binding, but he
didn't want to.

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.

The clash of M-s prefix with Icicles' search binding is a third issue.
But I guess we have to live with that.


Regards,

Michael.

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Not being able to perform Icicle search was not the problem, it is a
> problem the other way round: Icicles' binding is a minor mode binding,
> thus shadowing the Gnus M-s binding, which is really important.  That's
> the problem.  Without a keybinding, it is also harder to find, e.g. with
> C-h b etc.  I had suggested to Lars to change the Gnuish binding, but he
> didn't want to.

Well, icicles is a third-party library, so I think it's icicle's
responsibility to not step on major mode bindings.  So I don't think
there's anything here to be fixed in Emacs, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> > I had suggested to Lars to change the Gnuish binding, but he
> > didn't want to.

And AFAICT, Lars never even gave a reason, let alone a good reason.

> Well, icicles is a third-party library, so I think it's icicle's
> responsibility to not step on major mode bindings.  So I don't think
> there's anything here to be fixed in Emacs, and I'm closing this bug
> report.

It is you, Lars, who stepped on existing keybindings (first Isearch
and then Icicles).  Icicles has lots of keys bound on the prefix
key M-s M-s, and has had for a long time before you decided to
appropriate it (when it was pointed out that M-s is for Isearch).
The Gnus binding for M-s M-s is not even a prefix key.  Who's
hogging keys, here?

M-s M-s makes sense as a prefix key.  For a single command there
is no need for a quick double key like that, but there is for a
prefix to another key.  If Gnus, like Icicles, had many keys that
it wanted to put on prefix M-s M-s then you might have an argument,
at least, but that's not even the case.

Icicle mode is a global minor mode.  If Gnus is stubborn about
keeping M-s M-s for its single command then an Icicles user of
Gnus can always customize the prefix key used for the Icicles
search commands.  Or s?he can toggle Icicle mode off.  S?he
shouldn't have to do either, but so be it.

As I said before:

  I mention it as an existing conflict and suddenly it's a
  proposal for Gnus?

  So now you want to completely appropriate the key I complained
  about Gnus conflicting with, creating even more conflicts for
  Icicles?  Gee, thanks.

First, Gnus tried to appropriate M-s from Isearch.  When that
grab was exposed, Gnus appropriated M-s M-s, which is a prefix
key for Icicles, even though that too was pointed out.

Gee, thanks, indeed.  You're not very cooperative, Mr Ingebrigtsen.

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

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> First, Gnus tried to appropriate M-s from Isearch.  When that
> grab was exposed, Gnus appropriated M-s M-s, which is a prefix
> key for Icicles, even though that too was pointed out.

> Gee, thanks, indeed. You're not very cooperative, Mr Ingebrigtsen.

Please, Drew, there is no need for such criticism here. You have both done
wonderful work over the years, so I know you both want what is best for Emacs.

Lars, M-s M-s strikes me as a bit strange for something that executes Gnus.
Perhaps M-s g, or M-s M-g?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

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

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Lars, M-s M-s strikes me as a bit strange for something that executes Gnus.
> Perhaps M-s g, or M-s M-g?

Well, the Gnus command is `M-s', not `M-s M-s'...

-------

M-s runs the command gnus-summary-search-article-forward (found in
gnus-summary-mode-map), which is an interactive compiled Lisp function
in ‘gnus-sum.el’.

It is bound to M-s, <menu-bar> <Gnus> <Search articles forward...>.

(gnus-summary-search-article-forward REGEXP &optional BACKWARD)

Search for an article containing REGEXP forward.
If BACKWARD, search backward instead.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, the Gnus command is `M-s', not `M-s M-s'...

So this is about a binding of M-s when Gnus is active?  As long as that's not
against the Elisp conventions for key bindings, what is the problem?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> So this is about a binding of M-s when Gnus is active?

Yes, in the summary buffer.  And it's been a binding there since the
mid-80s, if I recall correctly...

> As long as that's not against the Elisp conventions for key bindings,
> what is the problem?

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

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

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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.

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

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

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

Let's change the topic of this bug then, to be about whether M-s should be a
reserved key to be respected by all modes or not, and therefore require an
update to the Elisp convention. Lars, do you think this would be troublesome
for Gnus?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Drew Adams]

> > 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.
> 
> Let's change the topic of this bug then, to be about whether M-s should be a
> reserved key to be respected by all modes or not, and therefore require an
> update to the Elisp convention. Lars, do you think this would be troublesome
> for Gnus?

I'm not sure I'd advise that.  I think it might be better to leave
this `M-s' "rule" as it is, and thus leave uses by Emacs itself up to
Emacs Dev.

Users and 3rd-party library authors already understand, or will come
to understand, that Emacs itself uses `M-s' as a prefix for search keys,
and they will take that into account in deciding whether they want to
repurpose it.

IOW, if it is not cast in bronze in the `Key Binding Conventions' then
there is more leeway for judgment calls, case by case.  That might be
the best approach for this.  The list of official key reservations is
purposely quite limited, and that has not hurt Emacs.

And there will likely be other such decisions, as Emacs makes more
use of prefix keys (because keys are a limited resource).  That's my
expectation, at least: consolidation of related keys on prefix keys
(by default), such as was done for `M-s', in order to deal with a
shortage of keys.

In any case, IMHO, a decision whether to make `M-s' reserved should
not be based on, or even influenced by, whether doing that would be
troublesome for Gnus.

Reserving `M-s' is a bigger decision - even if it would not be
troublesome for Gnus, that should not be sufficient to decide to do
it.  And even if it is troublesome for Gnus, that should not be
sufficient to decide not to do it.

So I would prefer to see this bug dealt with, one way or another,
without deciding once and for all whether `M-s' should be reserved
per the published key-binding conventions.

Just one opinion (and I could be persuaded otherwise).

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

[Glenn Morris]

Please note the ancient FOR-RELEASE (now release-process) item

** Check for modes which bind M-s that conflicts with a new global
   binding M-s and change key bindings where necessary.  The current
   list of modes:

Gnus was there first.

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

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> So I would prefer to see this bug dealt with, one way or another, without
> deciding once and for all whether `M-s' should be reserved per the published
> key-binding conventions.

If there's no convention, then I think Gnus is free to choose here.  You can
make the argument to Lars to not use that binding, but then it's not really a
bug in any sense.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2