GNU bug report logs - #25318
24.5; Put `M-s' on a prefix keymap in Isearch

Previous Next

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

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

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.5; Put `M-s' on a prefix keymap in Isearch
Date: Sat, 31 Dec 2016 20:56:49 -0800 (PST)

Currently, `isearch-mode-map' has a number of key sequences bound in it
that begin with prefix-key `M-s':

M-s C-e		isearch-yank-line
M-s SPC		isearch-toggle-lax-whitespace
M-s '		isearch-toggle-char-fold
M-s _		isearch-toggle-symbol
M-s c		isearch-toggle-case-fold
M-s e		isearch-edit-string
M-s i		isearch-toggle-invisible
M-s o		isearch-occur
M-s r		isearch-toggle-regexp
M-s w		isearch-toggle-word
M-s h r		isearch-highlight-regexp

And 3rd-party libraries have added more such `M-s ...' keys.

But there is no keymap for prefix-key `M-s'.  There should be.

Please put all of the `M-s' prefixed keys on a separate, prefix-key
keymap, which itself is on `isearch-mode-map'.

Since these keys do not form any _specific_ grouping, I'd propose a
name for the keymap such as `isearch-misc-map' (better than nothing).

This will let users and other libraries move the prefix keymap to a
different prefix key if they want, or define `M-s C-h' to show only the
bindings on prefix `M-s', and so on.

As it stands now, a 3rd-party library cannot do what this bug report
requests, because there are likely other libraries, which may be loaded
before it, and which bind `M-s <whatever' directly in
`isearch-mode-map'.  Those bindings would be wiped out by a later
binding of `M-s' to a prefix map.

But if this is done in core Emacs then there will be no such problem
(there is no problem if a library binds `M-s <whatever>' directly in
`isearch-mode-map' AFTER the prefix map has been placed on
`isearch-mode-map).


In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 25318 <at> debbugs.gnu.org
Subject: Re: bug#25318: 24.5; Put `M-s' on a prefix keymap in Isearch
Date: Sun, 29 Sep 2019 19:37:30 +0200

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

> Currently, `isearch-mode-map' has a number of key sequences bound in it
> that begin with prefix-key `M-s':
>
> M-s C-e		isearch-yank-line
> M-s SPC		isearch-toggle-lax-whitespace
> M-s '		isearch-toggle-char-fold
> M-s _		isearch-toggle-symbol
> M-s c		isearch-toggle-case-fold
> M-s e		isearch-edit-string
> M-s i		isearch-toggle-invisible
> M-s o		isearch-occur
> M-s r		isearch-toggle-regexp
> M-s w		isearch-toggle-word
> M-s h r		isearch-highlight-regexp

[...]

> Since these keys do not form any _specific_ grouping, I'd propose a
> name for the keymap such as `isearch-misc-map' (better than nothing).

As you point out, these commands aren't functional grouping of any kind,
so I don't think it makes sense to put them on a separate map.  It's not
like anybody would want to put all those functions somewhere else, which
is the primary reason to have sub-keymaps.

> This will let users and other libraries move the prefix keymap to a
> different prefix key if they want, or define `M-s C-h' to show only the
> bindings on prefix `M-s', and so on.
>
> As it stands now, a 3rd-party library cannot do what this bug report
> requests, because there are likely other libraries, which may be loaded
> before it, and which bind `M-s <whatever' directly in
> `isearch-mode-map'.  Those bindings would be wiped out by a later
> binding of `M-s' to a prefix map.
>
> But if this is done in core Emacs then there will be no such problem
> (there is no problem if a library binds `M-s <whatever>' directly in
> `isearch-mode-map' AFTER the prefix map has been placed on
> `isearch-mode-map).

So your use case is that you want to bind `M-s' to a prefix map
out-of-tree?  

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 25318 <at> debbugs.gnu.org
Subject: RE: bug#25318: 24.5; Put `M-s' on a prefix keymap in Isearch
Date: Sun, 29 Sep 2019 11:45:34 -0700 (PDT)

> > Currently, `isearch-mode-map' has a number of key sequences bound in it
> > that begin with prefix-key `M-s':...
> > Since these keys do not form any _specific_ grouping, I'd propose a
> > name for the keymap such as `isearch-misc-map' (better than nothing).
> 
> As you point out, these commands aren't functional grouping of any kind,
> so I don't think it makes sense to put them on a separate map.  It's not
> like anybody would want to put all those functions somewhere else, which
> is the primary reason to have sub-keymaps.

They are all on the same prefix key.  So yes, there is a good reason why someone might "want to put all those functions somewhere else": to put them on another prefix key.

That's the raison d'etre for a prefix-map variable: to be able to easily reuse or move all of its bindings at once, e.g. to another prefix key.

If there's a reason why each of the commands is on prefix key `M-s' then the same reason applies for putting them on another prefix key - move/reuse them all, together.

Whether one or more of those commands shouldn't really be on the same prefix key is a separate question, for the maintainers of isearch.el to consider.  It's unrelated to the need/desire to grab put all of the `M-s' commands on another (additional or replacement) prefix key.

> > This will let users and other libraries move the prefix keymap to a
> > different prefix key if they want, or define `M-s C-h' to show only the
> > bindings on prefix `M-s', and so on.

Clear, no?  Both the 1st part and the 2nd, regarding `M-s C-h'.  The desire to offer `M-s C-h' is an additional reason to add a prefix-key variable for prefix key `M-s'.

> > As it stands now, a 3rd-party library cannot do what this bug report
> > requests, because there are likely other libraries, which may be loaded
> > before it, and which bind `M-s <whatever' directly in
> > `isearch-mode-map'.  Those bindings would be wiped out by a later
> > binding of `M-s' to a prefix map.

Also clear, no?

> > But if this is done in core Emacs then there will be no such problem
> > (there is no problem if a library binds `M-s <whatever>' directly in
> > `isearch-mode-map' AFTER the prefix map has been placed on
> > `isearch-mode-map).
> 
> So your use case is that you want to bind `M-s' to a prefix map
> out-of-tree?

Sorry, I don't know what "out-of-tree" means.

See above for the reasons for this request.  It's not about wanting to bind `M-s'.  It's about wanting to bind another prefix key.  And it's about providing `M-s C-h'.  The prefix key should have a keymap, usable by users and libraries.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 25318 <at> debbugs.gnu.org
Subject: Re: bug#25318: 24.5; Put `M-s' on a prefix keymap in Isearch
Date: Mon, 30 Sep 2019 07:31:40 +0200

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

> See above for the reasons for this request.  It's not about wanting to
> bind `M-s'.  It's about wanting to bind another prefix key.  And it's
> about providing `M-s C-h'.  The prefix key should have a keymap,
> usable by users and libraries.

Sorry; I don't see the use case since these commands have very little to
do with each other.  Closing.

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

Previous Next

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