GNU bug report logs - #43308
28.0.50; Improvements to Edit->Search menu

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 43308 in the body.
You can then email your comments to 43308 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: Ihor Radchenko <yantar92 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 22:18:51 +0800

Following up with "Changes for emacs 28" discussion about improving menu
[1]

Source: http://ergoemacs.org/emacs/modernization_menu.html

The following menus seems to be more confusing than helpful:
- Edit->Search menu->String Forward
- Edit->Search menu->String Backwards
- Edit->Search menu->Regexp Forward
- Edit->Search menu->Regexp Backwards
- Edit->Search menu->Repeat Forward
- Edit->Search menu->Repeat Backwards

In most of other applications, the search functionality is squeezed into
single search dialogue, providing searching forward, backwards, and
repeating search together (via next/prev buttons).
Current Emacs menu forces the user to click Edit->Search menu->...
multiple times to repeat the search. That is not a pleasant experience.

Also, the functionality of the above menu items seems to be strictly
inferior in comparison with isearch items from Edit->Search->Incremental
search sub-menu. The only apparent advantage is that user would not need
to know that moving to next/prev match is C-s/C-r.

The article suggests to remove the above Search menu items completely
and replace them by incremental search versions.

I would also add that we can show transient next match/previous match
toolbar icons to assist users, unfamiliar with key bindings. Though need
to make sure that these new toolbar icons can be easily associated with
the search process. For example, we may show additional toolbar at the
bottom (above the mini-buffer isearch prompt) with only these two new
toolbar icons (maybe also "exit search" icon).

Also, the article suggests to rename "Forward/Backward String..." into
"Search Forward/Backwards...", which sounds reasonable since
non-programmer users may be confused by the meaning of word "String".

Finally, find "Search tagged files..." and the following "Repeat" menu
confusing. What does "tagged files" mean? I tried to click it, got a
prompt about regex, then prompt about tag table (what is it?). Finally,
I got error "File ~/TAGS does not exist". This made me recall vague
memory about Emacs manual talking about some kind of completion feature
for large code projects - something I never used.

The above is my actual first impression. The menu seems useless for me,
though may have a value for programmers. However, I have two
suggestions:

1. Menu items do not show the key binding (is in Incremental search
   menu). I think that showing bindings is generally a great idea for
   discoverability

2. There is currently no way to understand what some unfamiliar menus do
   except blindly trying. As I explained about, it does not always help.
   Probably, Emacs could show some kind of tooltip on top of menu items,
   explaining what it does in more details. Also, it would be cool to be
   able to move to Manual page talking about topic relevant to the menu
   item (on right click?).

Best,
Ihor


[1] https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00410.html

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-08-15 built on localhost
Repository revision: f712cdbe9e9bdca3d4c7c27e9ac59686ab4c7620
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Gentoo/Linux

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 17:59:12 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Thu, 10 Sep 2020 22:18:51 +0800
> 
> The following menus seems to be more confusing than helpful:
> - Edit->Search menu->String Forward
> - Edit->Search menu->String Backwards
> - Edit->Search menu->Regexp Forward
> - Edit->Search menu->Regexp Backwards
> - Edit->Search menu->Repeat Forward
> - Edit->Search menu->Repeat Backwards

I disagree.  Many applications have only the non-incremental search
commands, so removing them will leave the user who are used to those
with the incremental variant, which might be confusing for people who
have no experience with comparable commands.

> In most of other applications, the search functionality is squeezed into
> single search dialogue, providing searching forward, backwards, and
> repeating search together (via next/prev buttons).
> Current Emacs menu forces the user to click Edit->Search menu->...
> multiple times to repeat the search. That is not a pleasant experience.

If you are suggesting a "repeat last search" menu item, it could be a
useful idea.  But removing those items because we don't have a simple
repeat item is a step in the wrong direction, IMO.

> Also, the functionality of the above menu items seems to be strictly
> inferior in comparison with isearch items from Edit->Search->Incremental
> search sub-menu.

See above: it is there for those who are not familiar enough with the
incremental variants.

Please don't forget that the menu bar targets mainly newcomers, so
judging it from the POV of a veteran Emacs user might yield incorrect
conclusions.

> I would also add that we can show transient next match/previous match
> toolbar icons to assist users, unfamiliar with key bindings.

Please show the code.  Please also keep in mind that changes on the
tool bar require redrawing of the tool bar, which could cause
unpleasant flickering.  We need to consider this potential downside.

> Also, the article suggests to rename "Forward/Backward String..." into
> "Search Forward/Backwards...", which sounds reasonable since
> non-programmer users may be confused by the meaning of word "String".

The "Search" part is in the parent menu item, so repeating it would be
a waste of space, which is at premium here.

If people agree that removing "String" will help, maybe we could do
that.  But please note that "String" contrasts with "Regexp" in the
next items; if we remove it, won't that be less clear?

> Finally, find "Search tagged files..." and the following "Repeat" menu
> confusing. What does "tagged files" mean?

Feel free to suggest a better name for the item and/or a better help
string.

> I tried to click it, got a prompt about regex, then prompt about tag
> table (what is it?). Finally, I got error "File ~/TAGS does not
> exist". This made me recall vague memory about Emacs manual talking
> about some kind of completion feature for large code projects -
> something I never used.

Did you try "C-h k" before selecting that?  This would display the
documentation of that command.  It's a canonical way of learning about
menu items that don't explain themselves enough at first reading.  (Of
course if we can make them more self-explanatory, it's better.)

> 1. Menu items do not show the key binding (is in Incremental search
>    menu). I think that showing bindings is generally a great idea for
>    discoverability

If there's no key binding shown in the menu, it means the command
invoked by the menu item doesn't have a key.  When there's a key
binding, the machinery that displays the menu adds them automatically.

> 2. There is currently no way to understand what some unfamiliar menus do
>    except blindly trying.

See above: "C-h k" is the way to understand that.

Thanks.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 08:38:04 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> I disagree.  Many applications have only the non-incremental search
> commands, so removing them will leave the user who are used to those
> with the incremental variant, which might be confusing for people who
> have no experience with comparable commands.

I think this is less of a concern these days.

The applications you talk about also have search dialog boxes, which
make the non-incremental search actually useful.

Firefox also has incremental search by default, which many (most?) of
our users will already be familiar with.

>> In most of other applications, the search functionality is squeezed into
>> single search dialogue, providing searching forward, backwards, and
>> repeating search together (via next/prev buttons).
>> Current Emacs menu forces the user to click Edit->Search menu->...
>> multiple times to repeat the search. That is not a pleasant experience.
>
> If you are suggesting a "repeat last search" menu item, it could be a
> useful idea.  But removing those items because we don't have a simple
> repeat item is a step in the wrong direction, IMO.

This is a separate discussion, I think, but on graphical displays I
would ideally like to see a user interface like the one in C-f Firefox.
It shows clickable buttons for next/previous match, toggles for "Match
Case", "Whole Words" and how many matches there are.

>> I would also add that we can show transient next match/previous match
>> toolbar icons to assist users, unfamiliar with key bindings.
>
> Please show the code.  Please also keep in mind that changes on the
> tool bar require redrawing of the tool bar, which could cause
> unpleasant flickering.  We need to consider this potential downside.

Alternatively, see my suggestion about doing it like Firefox above.
IMHO, the tool bar is not a place where you would expect to find this.

>> Also, the article suggests to rename "Forward/Backward String..." into
>> "Search Forward/Backwards...", which sounds reasonable since
>> non-programmer users may be confused by the meaning of word "String".
>
> The "Search" part is in the parent menu item, so repeating it would be
> a waste of space, which is at premium here.
>
> If people agree that removing "String" will help, maybe we could do
> that.  But please note that "String" contrasts with "Regexp" in the
> next items; if we remove it, won't that be less clear?

I think removing it is fine.  Already saying "Regexp" makes it clear
that this is the odd one out.

(IIRC, this is what you find in other software: the regexp case is the
one with a special mention, otherwise it's just called "Search".)

>> Finally, find "Search tagged files..." and the following "Repeat" menu
>> confusing. What does "tagged files" mean?
>
> Feel free to suggest a better name for the item and/or a better help
> string.

We could perhaps move it to a menu related to tags functionality?  Just
an idea.

>> 1. Menu items do not show the key binding (is in Incremental search
>>    menu). I think that showing bindings is generally a great idea for
>>    discoverability
>
> If there's no key binding shown in the menu, it means the command
> invoked by the menu item doesn't have a key.  When there's a key
> binding, the machinery that displays the menu adds them automatically.

Right.  The problem here is that these commands are specifically
designed to be run from the menu.  Is there any way to work around that?

>> 2. There is currently no way to understand what some unfamiliar menus do
>>    except blindly trying.
>
> See above: "C-h k" is the way to understand that.

Maybe this should be clarified more in the doc string of C-h k.  I never
realized you can use "C-h k" to find out more about menu options, but I
suppose it makes sense now that you mention it.

Perhaps we could add a special command under the "Help" menu that says
"Help for menu" that when clicked runs C-h k with a special message in
the mini-buffer "Click the menu command you want help for"?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 18:51:12 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 10 Sep 2020 08:38:04 -0700
> Cc: 43308 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I disagree.  Many applications have only the non-incremental search
> > commands, so removing them will leave the user who are used to those
> > with the incremental variant, which might be confusing for people who
> > have no experience with comparable commands.
> 
> I think this is less of a concern these days.

In what way is this less of a concern?

> The applications you talk about also have search dialog boxes, which
> make the non-incremental search actually useful.

That's true in some cases, but not in all of them.  And the dialog is
not really relevant here: the issue I raise is with the concept of
incremental searching being unfamiliar.

> Firefox also has incremental search by default, which many (most?) of
> our users will already be familiar with.

Some applications added incremental search, but many don't have it,
and probably never will.  Simple editors are in that class.

> > If you are suggesting a "repeat last search" menu item, it could be a
> > useful idea.  But removing those items because we don't have a simple
> > repeat item is a step in the wrong direction, IMO.
> 
> This is a separate discussion, I think, but on graphical displays I
> would ideally like to see a user interface like the one in C-f Firefox.
> It shows clickable buttons for next/previous match, toggles for "Match
> Case", "Whole Words" and how many matches there are.

Improving the (non-existing) search dialog is a separate discussion.
If you want to work on such a dialog, please do.  but that is not what
we are talking here.  The proposal on the table is to remove
non-incremental search commands from the Search menu.  let's stay
focused on that issue, okay?

> > Feel free to suggest a better name for the item and/or a better help
> > string.
> 
> We could perhaps move it to a menu related to tags functionality?  Just
> an idea.

No, I think this is fundamentally a search command.  TAGS is just an
aid.

> >> 1. Menu items do not show the key binding (is in Incremental search
> >>    menu). I think that showing bindings is generally a great idea for
> >>    discoverability
> >
> > If there's no key binding shown in the menu, it means the command
> > invoked by the menu item doesn't have a key.  When there's a key
> > binding, the machinery that displays the menu adds them automatically.
> 
> Right.  The problem here is that these commands are specifically
> designed to be run from the menu.  Is there any way to work around that?

What kind of workaround do you have in mind?

> >> 2. There is currently no way to understand what some unfamiliar menus do
> >>    except blindly trying.
> >
> > See above: "C-h k" is the way to understand that.
> 
> Maybe this should be clarified more in the doc string of C-h k.  I never
> realized you can use "C-h k" to find out more about menu options, but I
> suppose it makes sense now that you mention it.

There's something new to learn about Emacs every day ;-)

> Perhaps we could add a special command under the "Help" menu that says
> "Help for menu" that when clicked runs C-h k with a special message in
> the mini-buffer "Click the menu command you want help for"?

I don't mind, if this will really help this to be more discoverable.
(Of course Xah Lee thinks that our Help menu is too large as it is...)

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 09:19:05 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > I disagree.  Many applications have only the non-incremental search
>> > commands, so removing them will leave the user who are used to those
>> > with the incremental variant, which might be confusing for people who
>> > have no experience with comparable commands.
>>
>> I think this is less of a concern these days.
>
> In what way is this less of a concern?

Users are more familiar with incremental search, for example from
Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
Assuming that our users have used any of those web browsers, they will
already have had exposure to incremental search.

In any case, even if they haven't, the feature will quickly be learned
once you start using it.

>> > If there's no key binding shown in the menu, it means the command
>> > invoked by the menu item doesn't have a key.  When there's a key
>> > binding, the machinery that displays the menu adds them automatically.
>>
>> Right.  The problem here is that these commands are specifically
>> designed to be run from the menu.  Is there any way to work around that?
>
> What kind of workaround do you have in mind?

I'm not sure.  Either we add specific workarounds for them in the menu
code, or we make sure the original commands are adapted to suit this
task.  But it would be good to show the keybindings, since one of the
main purposes of the menu is to make functionality discoverable.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 19:30:02 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 10 Sep 2020 09:19:05 -0700
> Cc: yantar92 <at> gmail.com, 43308 <at> debbugs.gnu.org
> 
> >> I think this is less of a concern these days.
> >
> > In what way is this less of a concern?
> 
> Users are more familiar with incremental search, for example from
> Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> Assuming that our users have used any of those web browsers, they will
> already have had exposure to incremental search.

The example apps you show are not editors.

> In any case, even if they haven't, the feature will quickly be learned
> once you start using it.

The menus are supposed to help first-time users, with little or no
experience in using Emacs.  Once they start using the incremental
search, the menus are probably not for them anymore.

> >> Right.  The problem here is that these commands are specifically
> >> designed to be run from the menu.  Is there any way to work around that?
> >
> > What kind of workaround do you have in mind?
> 
> I'm not sure.  Either we add specific workarounds for them in the menu
> code, or we make sure the original commands are adapted to suit this
> task.  But it would be good to show the keybindings, since one of the
> main purposes of the menu is to make functionality discoverable.

The problem is that the key sequence invokes a different command.

About the only solution I see is to mention the keyboard equivalent in
the doc string of the command invoked by the menu.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stefankangas <at> gmail.com
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 19:38:12 +0300

> Date: Thu, 10 Sep 2020 19:30:02 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
> 
> > Users are more familiar with incremental search, for example from
> > Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> > Assuming that our users have used any of those web browsers, they will
> > already have had exposure to incremental search.
> 
> The example apps you show are not editors.

And, btw, their incremental search works subtly differently: once you
click the Next or Previous button, typing characters doesn't
necessarily modify the search string, you need to click in the search
field for that.

So even if the user has some experience with these browsers, they
won't necessarily feel at home with Emacs's Isearch.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 21:36:31 +0300

>> > If you are suggesting a "repeat last search" menu item, it could be a
>> > useful idea.  But removing those items because we don't have a simple
>> > repeat item is a step in the wrong direction, IMO.
>> 
>> This is a separate discussion, I think, but on graphical displays I
>> would ideally like to see a user interface like the one in C-f Firefox.
>> It shows clickable buttons for next/previous match, toggles for "Match
>> Case", "Whole Words" and how many matches there are.
>
> Improving the (non-existing) search dialog is a separate discussion.
> If you want to work on such a dialog, please do.  but that is not what
> we are talking here.

I think there is no need in such dialog because when Isearch is active,
there is the isearch-specific tool-bar and Isearch submenu in the menu bar.

> The proposal on the table is to remove non-incremental search commands
> from the Search menu.

There is a menu item in the Isearch submenu named "Nonincremental search".

But it you really don't want to remove nonincremental menu items from
the Edit menu then they could be swapped with incremental menu items,
i.e. to promote incremental menu items higher, and demote nonincremental
menu items deeper to the submenu where currently more often used
incremental menu items are located.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 21:45:54 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  43308 <at> debbugs.gnu.org,
>   yantar92 <at> gmail.com
> Date: Thu, 10 Sep 2020 21:36:31 +0300
> 
> But it you really don't want to remove nonincremental menu items from
> the Edit menu then they could be swapped with incremental menu items,
> i.e. to promote incremental menu items higher, and demote nonincremental
> menu items deeper to the submenu where currently more often used
> incremental menu items are located.

That'd be the opposite of what the menu should be doing, which is
putting the easier and more familiar commands closer to the top level.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 22:14:00 +0300

>> But it you really don't want to remove nonincremental menu items from
>> the Edit menu then they could be swapped with incremental menu items,
>> i.e. to promote incremental menu items higher, and demote nonincremental
>> menu items deeper to the submenu where currently more often used
>> incremental menu items are located.
>
> That'd be the opposite of what the menu should be doing, which is
> putting the easier and more familiar commands closer to the top level.

TUTORIAL teaches about incremental commands:

  * SEARCHING
  -----------

  The Emacs search command is "incremental".  This means that the
  search happens while you type in the string to search for.

  The command to initiate a search is C-s for forward search, and C-r
  for reverse search.  BUT WAIT!  Don't try them now.

  When you type C-s you'll notice that the string "I-search" appears as
  a prompt in the echo area.  This tells you that Emacs is in what is
  called an incremental search waiting for you to type the thing that
  you want to search for.  <Return> terminates a search.

  Did you see what happened?  Emacs, in an incremental search, tries to
  go to the occurrence of the string that you've typed out so far.  To
  go to the next occurrence of "cursor" just type C-s again.  If no such
  occurrence exists, Emacs beeps and tells you the search is currently
  "failing".  C-g would also terminate the search.

  If you are in the middle of an incremental search and type <DEL>, the
...

so this is what newbies need to know and use from the menu.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 22:44:04 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: stefankangas <at> gmail.com,  43308 <at> debbugs.gnu.org,  yantar92 <at> gmail.com
> Date: Thu, 10 Sep 2020 22:14:00 +0300
> 
> >> But it you really don't want to remove nonincremental menu items from
> >> the Edit menu then they could be swapped with incremental menu items,
> >> i.e. to promote incremental menu items higher, and demote nonincremental
> >> menu items deeper to the submenu where currently more often used
> >> incremental menu items are located.
> >
> > That'd be the opposite of what the menu should be doing, which is
> > putting the easier and more familiar commands closer to the top level.
> 
> TUTORIAL teaches about incremental commands:

Once again, menus are for those who don't read the documentation, but
just start Emacs and want to do something useful.

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

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 28.0.50; Improvements to Edit->Search menu
Date: Sun, 13 Sep 2020 18:08:47 +0800

It seems that the opinions are a bit split here, so I am try to
summarise the current state of the discussion in this message and refine
my suggestions from original bug report.

First of all, let me clarify on the purpose of the menu/toolbar as I
understand it. I tried to make sure that it is consistent with opinions
of others, but feel free to reply if you disagree.

Target users:

1. Menu is designed for users unfamiliar with Emacs concepts
2. Moreover, we do not expect those users to read Emacs manual or even
   tutorial
3. All the users are expected to know functionality, which is common
   among modern editor apps
4. Menu does not try to show all possible functionality of Emacs, just
   the most important (otherwise, people will be lost in too many menu
   items)

The aims of the menu:

1. Show people Emacs equivalents text editing functions they would
   expect to use from other editors
2. Provide an indication how to switch to Emacs-specific commands (by
   indicating key bindings and command help)
3. Provide the most important Emacs-specific commands, which can be
   useful even though they have no equivalent in other editors

Now, let me go through my original proposal and put in into the context
of the above principles, while taking into account the comments on this
bug report.

----------
1. Replacing non-interactive search by interactive search
----------

There seems to be controversy on this part of the proposal:

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> I disagree.  Many applications have only the non-incremental search
> commands, so removing them will leave the user who are used to those
> with the incremental variant, which might be confusing for people who
> have no experience with comparable commands.

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous
message

> I think this is less of a concern these days.
> 
> The applications you talk about also have search dialog boxes, which
> make the non-incremental search actually useful.
> 
> Firefox also has incremental search by default, which many (most?) of
> our users will already be familiar with.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 23:51) replying to previous message

>> The applications you talk about also have search dialog boxes, which
>> make the non-incremental search actually useful.
>
> That's true in some cases, but not in all of them.  And the dialog is
> not really relevant here: the issue I raise is with the concept of
> incremental searching being unfamiliar.
>
>> Firefox also has incremental search by default, which many (most?) of
>> our users will already be familiar with.
>
> Some applications added incremental search, but many don't have it,
> and probably never will.  Simple editors are in that class.

Stefan Kangas <stefankangas <at> gmail.com> (Fri. 00:19) replying to previous message

>> In what way is this less of a concern?
>
> Users are more familiar with incremental search, for example from
> Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> Assuming that our users have used any of those web browsers, they will
> already have had exposure to incremental search.
>
> In any case, even if they haven't, the feature will quickly be learned
> once you start using it.


Eli Zaretskii <eliz <at> gnu.org> (Fri. 00:30) replying to previous message

> > > In what way is this less of a concern?
> > 
> > Users are more familiar with incremental search, for example from
> > Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> > Assuming that our users have used any of those web browsers, they will
> > already have had exposure to incremental search.
> 
> The example apps you show are not editors.
>
> And, btw, their incremental search works subtly differently: once you
> click the Next or Previous button, typing characters doesn't
> necessarily modify the search string, you need to click in the search
> field for that.
> 
> So even if the user has some experience with these browsers, they
> won't necessarily feel at home with Emacs's Isearch.
> 
> > In any case, even if they haven't, the feature will quickly be learned
> > once you start using it.
> 
> The menus are supposed to help first-time users, with little or no
> experience in using Emacs.  Once they start using the incremental
> search, the menus are probably not for them anymore.

My reply:

The above comment that incremental search may be unfamiliar is a valid
concern. However, non-interactive search is not commonly used in Emacs
by people who get some minimal experience (correct me if I am wrong). We
are promoting the command that may be relatively easy to used for the
user, but it does not help the user to learn the more common and
powerful Emacs equivalent (which is isearch).

As Stefan Kangas mentioned, we can expect that users are somehow
familiar with incremental search concept from browsers. People
unfamiliar with browsers are very uncommon case - if we start to
consider all such possibilities, menu will grow into duplicate of custom
interface (in terms to overly too many features).

It was also mentioned that isearch behaves differently from what users
might expect. However, the non-interactive search also behaves very
differently - users cannot go to next/previous match easily. They have
to go to menu->edit->search->repeat forward/backwards. On the contrary,
isearch does provide forward/backward search buttons at least (though
they are located far from the entered search string - in the toolbar). I
would argue that isearch does a better (not ideal though) job creating
familiar interface.

Therefore, I would favour isearch over the non-interactive version.

-----------
2. Showing next match/previous match toolbar icons to assist users, unfamiliar with key bindings
-----------

When writing this suggestion, I did not know that these icons are
already shown on the toolbar. In fact, toolbar during isearch does even
better job - it provides next/prev match _and_ more useful commands from
isearch-mode-map. Moreover, it even gives a button to show help buffer
about isearch.

There is no such toolbar functionality for non-interactive search
though.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > I would also add that we can show transient next match/previous match
> > toolbar icons to assist users, unfamiliar with key bindings.
> 
> Please show the code.  Please also keep in mind that changes on the
> tool bar require redrawing of the tool bar, which could cause
> unpleasant flickering.  We need to consider this potential downside.

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous message

> >> repeating search together (via next/prev buttons).
> >> Current Emacs menu forces the user to click Edit->Search menu->...
> >> multiple times to repeat the search. That is not a pleasant experience.
> >
> > If you are suggesting a "repeat last search" menu item, it could be a
> > useful idea.  But removing those items because we don't have a simple
> > repeat item is a step in the wrong direction, IMO.
> 
> This is a separate discussion, I think, but on graphical displays I
> would ideally like to see a user interface like the one in C-f Firefox.
> It shows clickable buttons for next/previous match, toggles for "Match
> Case", "Whole Words" and how many matches there are.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 23:51) replying to previous comment

> > > repeat item is a step in the wrong direction, IMO.
> > 
> > This is a separate discussion, I think, but on graphical displays I
> > would ideally like to see a user interface like the one in C-f Firefox.
> > It shows clickable buttons for next/previous match, toggles for "Match
> > Case", "Whole Words" and how many matches there are.
> 
> Improving the (non-existing) search dialog is a separate discussion.
> If you want to work on such a dialog, please do.  but that is not what
> we are talking here.  The proposal on the table is to remove
> non-incremental search commands from the Search menu.  let's stay
> focused on that issue, okay?

My reply:

I think I need to clarify that by showing toolbar buttons during search,
I proposed something similar to C-f in Firefox - buttons for prev/next
search are shown right above/below the input box for search string.

In the case of Emacs, that would mean showing prev/next match toolbar
buttons right above the minibuffer.

Moreover, as I mentioned earlier, there is already toolbar functionality
for isearch. If the toolbar was moved to the bottom of the frame during
isearch, it would be sufficient to achieve what I had in mind. Current
top position is very easy to miss (I did miss it even though I was
looking into isearch menu item specifically).

I believe that the same functionality can be implemented for
non-interactive search - we can reuse the same toolbar as in isearch.
Moreover, having prev/next match buttons will effectively provide the
following separate menu items in a single search command (or maybe in
two commands for forward/backward search):
- Edit->Search menu->String Forward
- Edit->Search menu->String Backwards
- Edit->Search menu->Regexp Forward
- Edit->Search menu->Regexp Backwards
- Edit->Search menu->Repeat Forward
- Edit->Search menu->Repeat Backwards

Same with isearch, I believe that the toolbar position would better be
right above the minibuffer.

On the flickering issue: Does it exist with the current toolbar for
isearch? If there no bug reports on it, it is probably just hypothetical
and we should not care about it.

----------
3. Renaming Forward/Backward string to Search forward/backward
----------

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > Also, the article suggests to rename "Forward/Backward String..." into
> > "Search Forward/Backwards...", which sounds reasonable since
> > non-programmer users may be confused by the meaning of word "String".
> 
> The "Search" part is in the parent menu item, so repeating it would be
> a waste of space, which is at premium here.
> 
> If people agree that removing "String" will help, maybe we could do
> that.  But please note that "String" contrasts with "Regexp" in the
> next items; if we remove it, won't that be less clear?

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous message

> > The "Search" part is in the parent menu item, so repeating it would be
> > a waste of space, which is at premium here.
> >
> > If people agree that removing "String" will help, maybe we could do
> > that.  But please note that "String" contrasts with "Regexp" in the
> > next items; if we remove it, won't that be less clear?
> 
> I think removing it is fine.  Already saying "Regexp" makes it clear
> that this is the odd one out.
> 
> (IIRC, this is what you find in other software: the regexp case is the
> one with a special mention, otherwise it's just called "Search".)

My reply:

No space will be wasted when renaming "Forward/Backward string" to
"Search forward/backward". The char count is the same. But, as I said we
add an extra benefit of not using word that is potentially confusing for
non-programmers.

------
4. Unfamiliar "Search tagged files..." command and other menu items,
   that user is not familiar with (yet)
------

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > Finally, find "Search tagged files..." and the following "Repeat" menu
> > confusing. What does "tagged files" mean?
> 
> Feel free to suggest a better name for the item and/or a better help
> string.

> > I tried to click it, got a prompt about regex, then prompt about tag
> > table (what is it?). Finally, I got error "File ~/TAGS does not
> > exist". This made me recall vague memory about Emacs manual talking
> > about some kind of completion feature for large code projects -
> > something I never used.
> 
> Did you try "C-h k" before selecting that?  This would display the
> documentation of that command.  It's a canonical way of learning about
> menu items that don't explain themselves enough at first reading.  (Of
> course if we can make them more self-explanatory, it's better.)

My reply:

> Feel free to suggest a better name for the item and/or a better help
> string.

I cannot suggest a better name since I have no idea how the TAGS
functionality works. I just wanted to point out that it was confusing
for me. I never had to deal with big multi-file projects where TAGS
search is needed.

> Did you try "C-h k" before selecting that?  This would display the
> documentation of that command.  It's a canonical way of learning about
> menu items that don't explain themselves enough at first reading.  (Of
> course if we can make them more self-explanatory, it's better.)

As you said in another message:

> Once again, menus are for those who don't read the documentation, but
> just start Emacs and want to do something useful.

We cannot expect the user to know about "C-h k".

My concrete suggestion is using the tooltip to hint the user how to get
more information about the command. The tooltip is already showing a
short (yet longer than menu item name) command description. I suggest to
add something like "Use mouse-3 (middle click) to get more information"
and bind mouse-3 to show help buffer on the command.

Best,
Ihor


Ihor Radchenko <yantar92 <at> gmail.com> writes:

> Following up with "Changes for emacs 28" discussion about improving menu
> [1]
>
> Source: http://ergoemacs.org/emacs/modernization_menu.html
>
> The following menus seems to be more confusing than helpful:
> - Edit->Search menu->String Forward
> - Edit->Search menu->String Backwards
> - Edit->Search menu->Regexp Forward
> - Edit->Search menu->Regexp Backwards
> - Edit->Search menu->Repeat Forward
> - Edit->Search menu->Repeat Backwards
>
> In most of other applications, the search functionality is squeezed into
> single search dialogue, providing searching forward, backwards, and
> repeating search together (via next/prev buttons).
> Current Emacs menu forces the user to click Edit->Search menu->...
> multiple times to repeat the search. That is not a pleasant experience.
>
> Also, the functionality of the above menu items seems to be strictly
> inferior in comparison with isearch items from Edit->Search->Incremental
> search sub-menu. The only apparent advantage is that user would not need
> to know that moving to next/prev match is C-s/C-r.
>
> The article suggests to remove the above Search menu items completely
> and replace them by incremental search versions.
>
> I would also add that we can show transient next match/previous match
> toolbar icons to assist users, unfamiliar with key bindings. Though need
> to make sure that these new toolbar icons can be easily associated with
> the search process. For example, we may show additional toolbar at the
> bottom (above the mini-buffer isearch prompt) with only these two new
> toolbar icons (maybe also "exit search" icon).
>
> Also, the article suggests to rename "Forward/Backward String..." into
> "Search Forward/Backwards...", which sounds reasonable since
> non-programmer users may be confused by the meaning of word "String".
>
> Finally, find "Search tagged files..." and the following "Repeat" menu
> confusing. What does "tagged files" mean? I tried to click it, got a
> prompt about regex, then prompt about tag table (what is it?). Finally,
> I got error "File ~/TAGS does not exist". This made me recall vague
> memory about Emacs manual talking about some kind of completion feature
> for large code projects - something I never used.
>
> The above is my actual first impression. The menu seems useless for me,
> though may have a value for programmers. However, I have two
> suggestions:
>
> 1. Menu items do not show the key binding (is in Incremental search
>    menu). I think that showing bindings is generally a great idea for
>    discoverability
>
> 2. There is currently no way to understand what some unfamiliar menus do
>    except blindly trying. As I explained about, it does not always help.
>    Probably, Emacs could show some kind of tooltip on top of menu items,
>    explaining what it does in more details. Also, it would be cool to be
>    able to move to Manual page talking about topic relevant to the menu
>    item (on right click?).
>
> Best,
> Ihor
>
>
> [1] https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00410.html
>
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
>  of 2020-08-15 built on localhost
> Repository revision: f712cdbe9e9bdca3d4c7c27e9ac59686ab4c7620
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: Gentoo/Linux

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

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Sun, 20 Sep 2020 15:15:10 +0800

It seems that the opinions are a bit split here, so I will try to
summarise the current state of the discussion in this message and refine
my suggestions from original bug report.

First of all, let me clarify on the purpose of the menu/toolbar as I
understand it. I tried to make sure that it is consistent with opinions
of others, but feel free to reply if you disagree.

Target users:

1. Menu is designed for users unfamiliar with Emacs concepts
2. Moreover, we do not expect those users to read Emacs manual or even
   tutorial
3. All the users are expected to know functionality, which is common
   among modern editor apps
4. Menu does not try to show all possible functionality of Emacs, just
   the most important (otherwise, people will be lost in too many menu
   items)

The aims of the menu:

1. Show people Emacs equivalents text editing functions they would
   expect to use from other editors
2. Provide an indication how to switch to Emacs-specific commands (by
   indicating key bindings and command help)
3. Provide the most important Emacs-specific commands, which can be
   useful even though they have no equivalent in other editors

Now, let me go through my original proposal and put in into the context
of the above principles, while taking into account the comments on this
bug report.

----------
1. Replacing non-interactive search by interactive search
----------

There seems to be controversy on this part of the proposal:

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> I disagree.  Many applications have only the non-incremental search
> commands, so removing them will leave the user who are used to those
> with the incremental variant, which might be confusing for people who
> have no experience with comparable commands.

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous
message

> I think this is less of a concern these days.
> The applications you talk about also have search dialog boxes, which
> make the non-incremental search actually useful.
> 
> Firefox also has incremental search by default, which many (most?) of
> our users will already be familiar with.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 23:51) replying to previous message

>> The applications you talk about also have search dialog boxes, which
>> make the non-incremental search actually useful.
[ 7 more citation lines. Click/Enter to show. ]
>
> That's true in some cases, but not in all of them.  And the dialog is
> not really relevant here: the issue I raise is with the concept of
> incremental searching being unfamiliar.
>
>> Firefox also has incremental search by default, which many (most?) of
>> our users will already be familiar with.
>
> Some applications added incremental search, but many don't have it,
> and probably never will.  Simple editors are in that class.

Stefan Kangas <stefankangas <at> gmail.com> (Fri. 00:19) replying to previous message

>> In what way is this less of a concern?
> Users are more familiar with incremental search, for example from
[ 3 more citation lines. Click/Enter to show. ]
> Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> Assuming that our users have used any of those web browsers, they will
> already have had exposure to incremental search.
>
> In any case, even if they haven't, the feature will quickly be learned
> once you start using it.

Eli Zaretskii <eliz <at> gnu.org> (Fri. 00:30) replying to previous message

> > > In what way is this less of a concern?
> > Users are more familiar with incremental search, for example from
[ 17 more citation lines. Click/Enter to show. ]
> > Firefox.  I checked, and Chromium also has it, and IIRC so does Safari.
> > Assuming that our users have used any of those web browsers, they will
> > already have had exposure to incremental search.
> 
> The example apps you show are not editors.
>
> And, btw, their incremental search works subtly differently: once you
> click the Next or Previous button, typing characters doesn't
> necessarily modify the search string, you need to click in the search
> field for that.
> 
> So even if the user has some experience with these browsers, they
> won't necessarily feel at home with Emacs's Isearch.
> 
> > In any case, even if they haven't, the feature will quickly be learned
> > once you start using it.
> 
> The menus are supposed to help first-time users, with little or no
> experience in using Emacs.  Once they start using the incremental
> search, the menus are probably not for them anymore.

My reply:

The above comment that incremental search may be unfamiliar is a valid
concern. However, non-interactive search is not commonly used in Emacs
by people who get some minimal experience (correct me if I am wrong). We
are promoting the command that may be relatively easy to used for the
user, but it does not help the user to learn the more common and
powerful Emacs equivalent (which is isearch).

As Stefan Kangas mentioned, we can expect that users are somehow
familiar with incremental search concept from browsers. People
unfamiliar with browsers are very uncommon case - if we start to
consider all such possibilities, menu will grow into duplicate of custom
interface (in terms to overly too many features).

It was also mentioned that isearch behaves differently from what users
might expect. However, the non-interactive search also behaves very
differently - users cannot go to next/previous match easily. They have
to go to menu->edit->search->repeat forward/backwards. On the contrary,
isearch does provide forward/backward search buttons at least (though
they are located far from the entered search string - in the toolbar). I
would argue that isearch does a better (not ideal though) job creating
familiar interface.

Therefore, I would favour isearch over the non-interactive version.

-----------
2. Showing next match/previous match toolbar icons to assist users, unfamiliar with key bindings
-----------

When writing this suggestion, I did not know that these icons are
already shown on the toolbar. In fact, toolbar during isearch does even
better job - it provides next/prev match _and_ more useful commands from
isearch-mode-map. Moreover, it even gives a button to show help buffer
about isearch.

There is no such toolbar functionality for non-interactive search
though.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > I would also add that we can show transient next match/previous match
> > toolbar icons to assist users, unfamiliar with key bindings.
> 
> Please show the code.  Please also keep in mind that changes on the
> tool bar require redrawing of the tool bar, which could cause
> unpleasant flickering.  We need to consider this potential downside.

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous message

> >> repeating search together (via next/prev buttons).
> >> Current Emacs menu forces the user to click Edit->Search menu->...
[ 7 more citation lines. Click/Enter to show. ]
> >> multiple times to repeat the search. That is not a pleasant experience.
> >
> > If you are suggesting a "repeat last search" menu item, it could be a
> > useful idea.  But removing those items because we don't have a simple
> > repeat item is a step in the wrong direction, IMO.
> 
> This is a separate discussion, I think, but on graphical displays I
> would ideally like to see a user interface like the one in C-f Firefox.
> It shows clickable buttons for next/previous match, toggles for "Match
> Case", "Whole Words" and how many matches there are.

Eli Zaretskii <eliz <at> gnu.org> (Thu. 23:51) replying to previous comment

> > > repeat item is a step in the wrong direction, IMO.
> > This is a separate discussion, I think, but on graphical displays I
[ 6 more citation lines. Click/Enter to show. ]
> > would ideally like to see a user interface like the one in C-f Firefox.
> > It shows clickable buttons for next/previous match, toggles for "Match
> > Case", "Whole Words" and how many matches there are.
> 
> Improving the (non-existing) search dialog is a separate discussion.
> If you want to work on such a dialog, please do.  but that is not what
> we are talking here.  The proposal on the table is to remove
> non-incremental search commands from the Search menu.  let's stay
> focused on that issue, okay?

My reply:

I think I need to clarify that by showing toolbar buttons during search,
I proposed something similar to C-f in Firefox - buttons for prev/next
search are shown right above/below the input box for search string.

In the case of Emacs, that would mean showing prev/next match toolbar
buttons right above the minibuffer.

Moreover, as I mentioned earlier, there is already toolbar functionality
for isearch. If the toolbar was moved to the bottom of the frame during
isearch, it would be sufficient to achieve what I had in mind. Current
top position is very easy to miss (I did miss it even though I was
looking into isearch menu item specifically).

I believe that the same functionality can be implemented for
non-interactive search - we can reuse the same toolbar as in isearch.
Moreover, having prev/next match buttons will effectively provide the
following separate menu items in a single search command (or maybe in
two commands for forward/backward search):
- Edit->Search menu->String Forward
- Edit->Search menu->String Backwards
- Edit->Search menu->Regexp Forward
- Edit->Search menu->Regexp Backwards
- Edit->Search menu->Repeat Forward
- Edit->Search menu->Repeat Backwards

Same with isearch, I believe that the toolbar position would better be
right above the minibuffer.

On the flickering issue: Does it exist with the current toolbar for
isearch? If there no bug reports on it, it is probably just hypothetical
and we should not care about it.

----------
3. Renaming Forward/Backward string to Search forward/backward
----------

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > Also, the article suggests to rename "Forward/Backward String..." into
> > "Search Forward/Backwards...", which sounds reasonable since
[ 5 more citation lines. Click/Enter to show. ]
> > non-programmer users may be confused by the meaning of word "String".
> 
> The "Search" part is in the parent menu item, so repeating it would be
> a waste of space, which is at premium here.
> 
> If people agree that removing "String" will help, maybe we could do
> that.  But please note that "String" contrasts with "Regexp" in the
> next items; if we remove it, won't that be less clear?

Stefan Kangas <stefankangas <at> gmail.com> (Thu. 23:38) replying to previous message

> > The "Search" part is in the parent menu item, so repeating it would be
> > a waste of space, which is at premium here.
[ 7 more citation lines. Click/Enter to show. ]
> >
> > If people agree that removing "String" will help, maybe we could do
> > that.  But please note that "String" contrasts with "Regexp" in the
> > next items; if we remove it, won't that be less clear?
> 
> I think removing it is fine.  Already saying "Regexp" makes it clear
> that this is the odd one out.
> 
> (IIRC, this is what you find in other software: the regexp case is the
> one with a special mention, otherwise it's just called "Search".)

My reply:

No space will be wasted when renaming "Forward/Backward string" to
"Search forward/backward". The char count is the same. But, as I said we
add an extra benefit of not using word that is potentially confusing for
non-programmers.

------
4. Unfamiliar "Search tagged files..." command and other menu items,
   that user is not familiar with (yet)
------

Eli Zaretskii <eliz <at> gnu.org> (Thu. 22:59)

> > Finally, find "Search tagged files..." and the following "Repeat" menu
> > confusing. What does "tagged files" mean?
[ 11 more citation lines. Click/Enter to show. ]
> 
> Feel free to suggest a better name for the item and/or a better help
> string.

> > I tried to click it, got a prompt about regex, then prompt about tag
> > table (what is it?). Finally, I got error "File ~/TAGS does not
> > exist". This made me recall vague memory about Emacs manual talking
> > about some kind of completion feature for large code projects -
> > something I never used.
> 
> Did you try "C-h k" before selecting that?  This would display the
> documentation of that command.  It's a canonical way of learning about
> menu items that don't explain themselves enough at first reading.  (Of
> course if we can make them more self-explanatory, it's better.)

My reply:

> Feel free to suggest a better name for the item and/or a better help
> string.

I cannot suggest a better name since I have no idea how the TAGS
functionality works. I just wanted to point out that it was confusing
for me. I never had to deal with big multi-file projects where TAGS
search is needed.

> Did you try "C-h k" before selecting that?  This would display the
> documentation of that command.  It's a canonical way of learning about
> menu items that don't explain themselves enough at first reading.  (Of
> course if we can make them more self-explanatory, it's better.)

As you said in another message:

> Once again, menus are for those who don't read the documentation, but
> just start Emacs and want to do something useful.

We cannot expect the user to know about "C-h k".

My concrete suggestion is using the tooltip to hint the user how to get
more information about the command. The tooltip is already showing a
short (yet longer than menu item name) command description. I suggest to
add something like "Use mouse-3 (middle click) to get more information"
and bind mouse-3 to show help buffer on the command.

Best,
Ihor


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: stefankangas <at> gmail.com,  43308 <at> debbugs.gnu.org,  yantar92 <at> gmail.com
>> Date: Thu, 10 Sep 2020 22:14:00 +0300
>> 
>> >> But it you really don't want to remove nonincremental menu items from
>> >> the Edit menu then they could be swapped with incremental menu items,
>> >> i.e. to promote incremental menu items higher, and demote nonincremental
>> >> menu items deeper to the submenu where currently more often used
>> >> incremental menu items are located.
>> >
>> > That'd be the opposite of what the menu should be doing, which is
>> > putting the easier and more familiar commands closer to the top level.
>> 
>> TUTORIAL teaches about incremental commands:
>
> Once again, menus are for those who don't read the documentation, but
> just start Emacs and want to do something useful.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Sun, 20 Sep 2020 11:10:19 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: stefankangas <at> gmail.com, 43308 <at> debbugs.gnu.org
> Date: Sun, 20 Sep 2020 15:15:10 +0800
> 
> It seems that the opinions are a bit split here, so I will try to
> summarise the current state of the discussion in this message and refine
> my suggestions from original bug report.

Thanks, but this method of summarizing the discussion by repeating
most of it is not useful.  It makes the "summary" very long and
tedious to read.  A summary should just show the main arguments
without citing the OPs.  People who want more details can always read
the archives.

> First of all, let me clarify on the purpose of the menu/toolbar as I
> understand it. I tried to make sure that it is consistent with opinions
> of others, but feel free to reply if you disagree.

I don't think there's disagreement about the principles.  When you
posted them the last time, I don't think anyone objected.  So I see no
need to reiterate them.

> Therefore, I would favour isearch over the non-interactive version.

And I'm against it.  Where does that leave us?

More generally, how is it useful to keep repeating your opinions which
are clearly not agreed to by at least some?  A useful step would be to
propose some compromise, or modify your proposal in some other way
that might take away some of the objections.

And what are we actually arguing about here?  Both non-incremental and
incremental search commands are already in the menus.  The proposal to
_remove_ the non-incremental commands is based on some (unproven)
assumptions, so it runs a risk of adversely affecting users which
those assumptions failed to consider.  Why take that risk?  I've seen
no answer to that question.  I agree that incremental search is more
powerful, but your principles don't (and shouldn't, IMO) state that we
want to show there only the most powerful commands.  So having both is
having the best of all worlds, and I see no reason to change that.

> It was also mentioned that isearch behaves differently from what users
> might expect. However, the non-interactive search also behaves very
> differently - users cannot go to next/previous match easily.

This can be fixed by providing tool-bar buttons for repeated search,
or reusing the buttons we already have for incremental search.  It's a
separate issue that is easy to fix, and no one objected to providing
this.  So it doesn't have to be an argument regarding the main issue
here.

> -----------
> 2. Showing next match/previous match toolbar icons to assist users, unfamiliar with key bindings
> -----------
> 
> When writing this suggestion, I did not know that these icons are
> already shown on the toolbar. In fact, toolbar during isearch does even
> better job - it provides next/prev match _and_ more useful commands from
> isearch-mode-map. Moreover, it even gives a button to show help buffer
> about isearch.
> 
> There is no such toolbar functionality for non-interactive search
> though.

Let's add it, then.  This would be a good improvement, I think.

> I think I need to clarify that by showing toolbar buttons during search,
> I proposed something similar to C-f in Firefox - buttons for prev/next
> search are shown right above/below the input box for search string.

Firefox is just one application.  Other applications show the
next/prev match just below the tool bar, above the text area.  I see
no reason why we couldn't do the latter.

> Moreover, as I mentioned earlier, there is already toolbar functionality
> for isearch. If the toolbar was moved to the bottom of the frame during
> isearch, it would be sufficient to achieve what I had in mind. Current
> top position is very easy to miss (I did miss it even though I was
> looking into isearch menu item specifically).

Moving the tool bar downwards is a non-starter in the context of this
discussion.  It means a very serious redesign of the Emacs display,
and will confuse many users.  It makes little sense to make such
significant changes, for a minor issue like this one, because we
insist on following the example of Firefox, instead of reusing what we
already have.

> Same with isearch, I believe that the toolbar position would better be
> right above the minibuffer.

We will not do this, not because of the search commands.

Feel free to start a more general discussion of moving the tool bar to
below the windows, but let's not complicate this particular discussion
by such grandiose and radical ideas.

> We cannot expect the user to know about "C-h k".

But we can expect them to know about the corresponding item in the
Help menu.

> My concrete suggestion is using the tooltip to hint the user how to get
> more information about the command.

Improving tooltips is of course welcome.  Please suggest text you
think will be more helpful.

Thanks.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: RE: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Sun, 20 Sep 2020 09:26:13 -0700 (PDT)

[Message part 1 (text/plain, inline)]

FWIW: Attached are screenshots showing the Search menu
that I use, in menu-bar+.el.

The only thing in the screenshots that isn't vanilla
is submenu Search > Icicles.  The rest is all vanilla.
There are 5 submenus (besides Icicles).

You can see how I deal with forward & backward, with
with incremental & nonincremental, and with repeated
nonincremental (forward & backward).  I think it's
pretty clear for users.

(I used to have nonincremental items at top level,
but moved them to a submenu because their use is
less common now.  Admittedly, if someone uses this a
lot then accessing via submenu is less efficient.)

__________
Search
  Incremental Search >
  Nonincremental Search >
  Replace >
  Xref >
  Tags >
__________
Files Regexp (`grep')...
This Buffer Regexp...
Buffers Regexp...
Buffers Regexp for Bufname Regexp...
__________

The last 3 items are for `occur', `multi-occur',
and `multi-occur-in-matching-buffers'.

[drew-emacs-menubar-Search-Incremental-Search.png (image/png, attachment)]

[drew-emacs-menubar-Search-Nonincremental-Search.png (image/png, attachment)]

[drew-emacs-menubar-Search-Replace.png (image/png, attachment)]

[drew-emacs-menubar-Search-Xref.png (image/png, attachment)]

[drew-emacs-menubar-Search-Tags.png (image/png, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Ihor Radchenko <yantar92 <at> gmail.com>, stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 22:05:02 +0300

> (I used to have nonincremental items at top level,
> but moved them to a submenu because their use is
> less common now.  Admittedly, if someone uses this a
> lot then accessing via submenu is less efficient.)

Why no keybindings are shown for nonincremental menu items?
They still have keybindings, e.g. nonincremental forward search
can be started with 'C-s RET', nonincremental backward search
with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> gmail.com>,
 Drew Adams <drew.adams <at> oracle.com>, stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 21:29:42 +0200

On Sep 21 2020, Juri Linkov wrote:

> Why no keybindings are shown for nonincremental menu items?
> They still have keybindings, e.g. nonincremental forward search
> can be started with 'C-s RET', nonincremental backward search
> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.

Those are not ordinary key bindings that can be discovered by
where-is-internal (which doesn't know about any temporary use of
overriding(-terminal)-local-map).

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Ihor Radchenko <yantar92 <at> gmail.com>, stefankangas <at> gmail.com
Subject: RE: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 12:30:43 -0700 (PDT)

> > (I used to have nonincremental items at top level,
> > but moved them to a submenu because their use is
> > less common now.  Admittedly, if someone uses this a
> > lot then accessing via submenu is less efficient.)
> 
> Why no keybindings are shown for nonincremental menu items?
> They still have keybindings, e.g. nonincremental forward search
> can be started with 'C-s RET', nonincremental backward search
> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.

I suppose I could add some explicitly, with :keys.
That makes sense.  Unfortunately, none show up
automatically.  It would be good to somehow fix that.
E.g., `C-h f nonincremental-search-forward':

  nonincremental-search-forward is an interactive compiled Lisp function
  in 'menu-bar.el'.

  It is bound to <menu-bar> <edit> <search> <search-forward>.

  (nonincremental-search-forward &optional STRING BACKWARD)

  Read a string and search for it nonincrementally.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>, Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> gmail.com>,
 stefankangas <at> gmail.com
Subject: RE: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 12:39:13 -0700 (PDT)

> Those are not ordinary key bindings that can be discovered by
> where-is-internal (which doesn't know about any temporary use of
> overriding(-terminal)-local-map).

Right.

(where-is-internal 'nonincremental-search-forward)

; ==> ([menu-bar edit search search-forward])

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com, drew.adams <at> oracle.com,
 stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 22:44:16 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Ihor Radchenko <yantar92 <at> gmail.com>,
>   43308 <at> debbugs.gnu.org,  stefankangas <at> gmail.com
> Date: Mon, 21 Sep 2020 22:05:02 +0300
> 
> Why no keybindings are shown for nonincremental menu items?

As usual, because the menu invokes different commands, not those for
which key sequences exist.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> gmail.com>,
 stefankangas <at> gmail.com
Subject: RE: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 21 Sep 2020 14:15:15 -0700 (PDT)

> > > (I used to have nonincremental items at top level,
> > > but moved them to a submenu because their use is
> > > less common now.  Admittedly, if someone uses this a
> > > lot then accessing via submenu is less efficient.)
> >
> > Why no keybindings are shown for nonincremental menu items?
> > They still have keybindings, e.g. nonincremental forward search
> > can be started with 'C-s RET', nonincremental backward search
> > with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
> 
> I suppose I could add some explicitly, with :keys.
> That makes sense.

I've done that now.

Of course, advertising such keys is a lie whenever
option `search-nonincremental-instead' is nil.

Too bad we can't have :keys be a sexp that is eval'd at
menu display/update time, and have a :keys value of nil
mean not to show any thing for the key bindings.

https://www.emacswiki.org/emacs/download/menu-bar%2b.el

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

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Ihor Radchenko <yantar92 <at> gmail.com>, stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Tue, 22 Sep 2020 11:04:58 +0300

>> Why no keybindings are shown for nonincremental menu items?
>> They still have keybindings, e.g. nonincremental forward search
>> can be started with 'C-s RET', nonincremental backward search
>> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
>
> I suppose I could add some explicitly, with :keys.
> That makes sense.  Unfortunately, none show up
> automatically.  It would be good to somehow fix that.

How about the following patch?

BTW, why "Search Tagged Files..." and "Continue Tags Search" have
no keybindings?

Another problem is that selecting "Continue Tags Search"
signals the error:

emacs -Q
Select "Edit" -> "Search" -> "Continue Tags Search"

  Lisp error: (wrong-type-argument commandp fileloop-continue)

I think "Continue Tags Search" should be disabled when it has no effect.

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 1556ee290f..901855402f 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -346,7 +346,9 @@ menu-bar-search-menu
                                    search-ring)
                               (and (eq menu-bar-last-search-type 'regexp)
                                    regexp-search-ring))
-                  :help "Repeat last search backwards"))
+                  :help "Repeat last search backwards"
+                  :keys "\\[isearch-backward] \\<isearch-mode-map>\\[isearch-exit]\
+ \\<minibuffer-local-isearch-map>\\[exit-minibuffer]"))
     (bindings--define-key menu [repeat-search-fwd]
       '(menu-item "Repeat Forward"
                   nonincremental-repeat-search-forward
@@ -354,26 +356,32 @@ menu-bar-search-menu
                                    search-ring)
                               (and (eq menu-bar-last-search-type 'regexp)
                                    regexp-search-ring))
-                  :help "Repeat last search forward"))
+                  :help "Repeat last search forward"
+                  :keys "\\[isearch-forward] \\<isearch-mode-map>\\[isearch-exit]\
+ \\<minibuffer-local-isearch-map>\\[exit-minibuffer]"))
     (bindings--define-key menu [separator-repeat-search]
       menu-bar-separator)
 
     (bindings--define-key menu [re-search-backward]
       '(menu-item "Regexp Backwards..."
                   nonincremental-re-search-backward
-                  :help "Search backwards for a regular expression"))
+                  :help "Search backwards for a regular expression"
+                  :keys "\\[isearch-backward-regexp] \\<isearch-mode-map>\\[isearch-exit]"))
     (bindings--define-key menu [re-search-forward]
       '(menu-item "Regexp Forward..."
                   nonincremental-re-search-forward
-                  :help "Search forward for a regular expression"))
+                  :help "Search forward for a regular expression"
+                  :keys "\\[isearch-forward-regexp] \\<isearch-mode-map>\\[isearch-exit]"))
 
     (bindings--define-key menu [search-backward]
       '(menu-item "String Backwards..."
                   nonincremental-search-backward
-                  :help "Search backwards for a string"))
+                  :help "Search backwards for a string"
+                  :keys "\\[isearch-backward] \\<isearch-mode-map>\\[isearch-exit]"))
     (bindings--define-key menu [search-forward]
       '(menu-item "String Forward..." nonincremental-search-forward
-                  :help "Search forward for a string"))
+                  :help "Search forward for a string"
+                  :keys "\\[isearch-forward] \\<isearch-mode-map>\\[isearch-exit]"))
     menu))
 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com, drew.adams <at> oracle.com,
 stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Tue, 22 Sep 2020 17:19:11 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Ihor Radchenko <yantar92 <at> gmail.com>,
>   43308 <at> debbugs.gnu.org,  stefankangas <at> gmail.com
> Date: Tue, 22 Sep 2020 11:04:58 +0300
> 
> >> Why no keybindings are shown for nonincremental menu items?
> >> They still have keybindings, e.g. nonincremental forward search
> >> can be started with 'C-s RET', nonincremental backward search
> >> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
> >
> > I suppose I could add some explicitly, with :keys.
> > That makes sense.  Unfortunately, none show up
> > automatically.  It would be good to somehow fix that.
> 
> How about the following patch?

But the keys this will show don't invoke the same commands, they
invoke slightly different commands, don't they?  I don't think we ever
show keys that invoke a different command, why do this here?

> Another problem is that selecting "Continue Tags Search"
> signals the error:
> 
> emacs -Q
> Select "Edit" -> "Search" -> "Continue Tags Search"
> 
>   Lisp error: (wrong-type-argument commandp fileloop-continue)

I guess this is a leftover from migration to Xref.

> I think "Continue Tags Search" should be disabled when it has no effect.

Yes, it should be.

Thanks.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Ihor Radchenko <yantar92 <at> gmail.com>, stefankangas <at> gmail.com
Subject: RE: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Tue, 22 Sep 2020 09:59:08 -0700 (PDT)

> >> Why no keybindings are shown for nonincremental menu items?
> >> They still have keybindings, e.g. nonincremental forward search
> >> can be started with 'C-s RET', nonincremental backward search
> >> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
> >
> > I suppose I could add some explicitly, with :keys.
> > That makes sense.  Unfortunately, none show up
> > automatically.  It would be good to somehow fix that.
> 
> How about the following patch?

It doesn't fix the nonautomatic display of keys, does it?

> BTW, why "Search Tagged Files..." and "Continue Tags Search" have
> no keybindings?

Because they have no keyboard key bindings.  Or was
that your question?  Did `tags-search' ever have a
default keyboard binding?  For `Continue Tags Search'
I think the reason was that when Emacs moved to xref
it dropped the `M-,' key binding for that command
(`tags-loop-continue').  (I wasn't in favor of that.)

> Another problem is that selecting "Continue Tags Search"
> signals the error:
> 
> emacs -Q
> Select "Edit" -> "Search" -> "Continue Tags Search"
> 
> Lisp error: (wrong-type-argument commandp fileloop-continue)

I don't see that with emacs -Q, loading menu-bar+.el,
and using that item in the Search menu (which is not
under Edit).  Dunno why.  I see just this error message:
"No operation in progress", which makes sense.

> I think "Continue Tags Search" should be disabled when it has no effect.

I've done that now, in menu-bar+.el.  I use this, but
perhaps someone can let me know if it's not the right,
or best, condition to use.  (I use condition-case, not
ignore-errors, for compatibility with older Emacs.)

:enable (not (condition-case nil
                 (tags-loop-eval tags-loop-scan)
               (error t)))

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com, drew.adams <at> oracle.com,
 stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Tue, 22 Sep 2020 21:10:13 +0300

>> >> Why no keybindings are shown for nonincremental menu items?
>> >> They still have keybindings, e.g. nonincremental forward search
>> >> can be started with 'C-s RET', nonincremental backward search
>> >> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
>> >
>> > I suppose I could add some explicitly, with :keys.
>> > That makes sense.  Unfortunately, none show up
>> > automatically.  It would be good to somehow fix that.
>>
>> How about the following patch?
>
> But the keys this will show don't invoke the same commands, they
> invoke slightly different commands, don't they?  I don't think we ever
> show keys that invoke a different command, why do this here?

The comment in 'nonincremental-search-forward' says:

  ;; Ideally, this whole command would be equivalent to `C-s RET'.

This seems to imply that currently it's not equivalent.
Then indeed displaying wrong keys would be misleading.

>> Another problem is that selecting "Continue Tags Search"
>> signals the error:
>>
>> emacs -Q
>> Select "Edit" -> "Search" -> "Continue Tags Search"
>>
>>   Lisp error: (wrong-type-argument commandp fileloop-continue)
>
> I guess this is a leftover from migration to Xref.

Do you mean these obsolete menu items should be removed since
now there are Xref commands in the "Go To" submenu?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com, drew.adams <at> oracle.com,
 stefankangas <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Tue, 22 Sep 2020 21:37:53 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: drew.adams <at> oracle.com,  yantar92 <at> gmail.com,  43308 <at> debbugs.gnu.org,
>   stefankangas <at> gmail.com
> Date: Tue, 22 Sep 2020 21:10:13 +0300
> 
> >> emacs -Q
> >> Select "Edit" -> "Search" -> "Continue Tags Search"
> >>
> >>   Lisp error: (wrong-type-argument commandp fileloop-continue)
> >
> > I guess this is a leftover from migration to Xref.
> 
> Do you mean these obsolete menu items should be removed since
> now there are Xref commands in the "Go To" submenu?

No, the commands do exist, but I think we have a bug there which
causes the error you saw.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 25 Apr 2022 12:46:04 +0200

Ihor Radchenko <yantar92 <at> gmail.com> writes:

> The article suggests to remove the above Search menu items completely
> and replace them by incremental search versions.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Eli didn't like that idea, but I wonder whether it makes sense to just
move "Incremental Search" up out of "Search"?  Because "Incremental
Search" is probably as popular as non-incremental search.

I.e., have both

Search
Incremental Search

directly under Edit.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 25 Apr 2022 14:36:44 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 43308 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Mon, 25 Apr 2022 12:46:04 +0200
> 
> I.e., have both
> 
> Search
> Incremental Search
> 
> directly under Edit.

I won't object to such a change, but IMO it's important to keep the
above order, i.e. not to put "Incremental Search" first.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 25 Apr 2022 14:10:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I won't object to such a change, but IMO it's important to keep the
> above order, i.e. not to put "Incremental Search" first.

OK; now done in Emacs 29.

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Ihor Radchenko <yantar92 <at> gmail.com>
Cc: "43308 <at> debbugs.gnu.org" <43308 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Mon, 25 Apr 2022 15:06:41 +0000

> I wonder whether it makes sense to just
> move "Incremental Search" up out of "Search"?  Because "Incremental
> Search" is probably as popular as non-incremental search.

The "because" is true, but it doesn't motivate such a move.

Leave all search under Search.  Don't add menus needlessly.

> I.e., have both
>  Search
>  Incremental Search
> directly under Edit.

(And I have a top-level Search menu on the menu-bar.)

Previous Next

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