bug#43308: 28.0.50; Improvements to Edit->Search menu

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Ihor Radchenko]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Stefan Kangas]

Eli Zaretskii <eliz@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"?

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 10 Sep 2020 08:38:04 -0700
> Cc: 43308@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@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...)

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Stefan Kangas]

Eli Zaretskii <eliz@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 10 Sep 2020 09:19:05 -0700
> Cc: yantar92@gmail.com, 43308@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 19:30:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 43308@debbugs.gnu.org, yantar92@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Juri Linkov]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  43308@debbugs.gnu.org,
>   yantar92@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Juri Linkov]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: stefankangas@gmail.com,  43308@debbugs.gnu.org,  yantar92@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Ihor Radchenko]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Ihor Radchenko]

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@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@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@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@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@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@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@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@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@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@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@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@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: stefankangas@gmail.com,  43308@debbugs.gnu.org,  yantar92@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: stefankangas@gmail.com, 43308@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

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

[-- Attachment #2: drew-emacs-menubar-Search-Incremental-Search.png --]
[-- Type: image/png, Size: 17185 bytes --]

[-- Attachment #3: drew-emacs-menubar-Search-Nonincremental-Search.png --]
[-- Type: image/png, Size: 18199 bytes --]

[-- Attachment #4: drew-emacs-menubar-Search-Replace.png --]
[-- Type: image/png, Size: 18196 bytes --]

[-- Attachment #5: drew-emacs-menubar-Search-Xref.png --]
[-- Type: image/png, Size: 17580 bytes --]

[-- Attachment #6: drew-emacs-menubar-Search-Tags.png --]
[-- Type: image/png, Size: 20387 bytes --]

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Juri Linkov]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Ihor Radchenko <yantar92@gmail.com>,
>   43308@debbugs.gnu.org,  stefankangas@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Juri Linkov]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Ihor Radchenko <yantar92@gmail.com>,
>   43308@debbugs.gnu.org,  stefankangas@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Juri Linkov]

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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: drew.adams@oracle.com,  yantar92@gmail.com,  43308@debbugs.gnu.org,
>   stefankangas@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.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Juri Linkov]

This is a new bug report spun off from bug#43308.

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

The error occurs only when fileloop.el is not yet loaded.

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

I tried this, but it doesn't enable "Continue Tags Search"
after starting "Search Tagged Files...".  And I don't know
what else could be checked.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> >> 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)))
> 
> I tried this, but it doesn't enable "Continue Tags Search"
> after starting "Search Tagged Files...".  And I don't know
> what else could be checked.

I think the xref changes broke the use of the tags code.
You can use `M-x tags-loop-continue'.  I think that
:enable code should work - and it does work for Emacs < 27.

But you're right that it no longer works.  Looks like the
code for the tags-search feature was changed partially,
and stuff was declared obsolete (which shouldn't have been
done, IMO).

* Xref as an alternative is one thing - OK.
* Xref as the new default is another thing - OK, but not my
  preference.
* Xref stealing the same keys is yet another thing - Not OK, IMO.
* But declaring the tags functionality and code to be
  obsolete is KO, IMO.  Overzealous NIH'ism, I expect.

Users should have both tags and xref available, as equals.

Guess I'll have to :enable that menu item unconditionally
for Emacs 27 and later (and leave it conditional for
Emacs before the breakage):

(define-key menu-bar-search-tags-menu [tags-continue]
  '(menu-item "Continue Tags Search/Replace" tags-loop-continue
    :help "Continue last tags search or replace operation"
    :enable (or (> emacs-major-version 26)
                (not (condition-case nil
                         (tags-loop-eval tags-loop-scan)
                       (error t))))))

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 13:44:36 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > >> 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)))
> > 
> > I tried this, but it doesn't enable "Continue Tags Search"
> > after starting "Search Tagged Files...".  And I don't know
> > what else could be checked.
> 
> I think the xref changes broke the use of the tags code.
> You can use `M-x tags-loop-continue'.  I think that
> :enable code should work - and it does work for Emacs < 27.

I tried to fix this on the emacs-27 branch, please take a look.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > > > :enable (not (condition-case nil
> > > >                  (tags-loop-eval tags-loop-scan)
> > > >                (error t)))
> > >
> > > I tried this, but it doesn't enable "Continue Tags Search"
> > > after starting "Search Tagged Files...".  And I don't know
> > > what else could be checked.
> >
> > I think the xref changes broke the use of the tags code.
> > You can use `M-x tags-loop-continue'.  I think that
> > :enable code should work - and it does work for Emacs < 27.
> 
> I tried to fix this on the emacs-27 branch, please take a look.

Someone else will need to do that, I'm afraid.

Or if you post something here that I can use
to replace the :enable code I showed, I'll be
glad to try that and let you know what I see.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 07:53:23 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> > I tried to fix this on the emacs-27 branch, please take a look.
> 
> Someone else will need to do that, I'm afraid.
> 
> Or if you post something here that I can use
> to replace the :enable code I showed, I'll be
> glad to try that and let you know what I see.

You can see the code via the Git Web interface offered by Savannah's
Emacs page.  I provided a link several times in the past.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > > I tried to fix this on the emacs-27 branch, please take a look.
> >
> > Someone else will need to do that, I'm afraid.
> >
> > Or if you post something here that I can use
> > to replace the :enable code I showed, I'll be
> > glad to try that and let you know what I see.
> 
> You can see the code via the Git Web interface offered by Savannah's
> Emacs page.  I provided a link several times in the past.

If you post something here that I can use to
replace the :enable code I showed, I'll be
glad to try that and let you know what I see.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 08:31:19 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> > You can see the code via the Git Web interface offered by Savannah's
> > Emacs page.  I provided a link several times in the past.
> 
> If you post something here that I can use to
> replace the :enable code I showed, I'll be
> glad to try that and let you know what I see.

Sigh...  As mentioned several times before, please go to

  https://git.savannah.gnu.org/cgit/emacs.git

Click on "emacs-27", find my change from a few hours ago, click on its
line, and you will see the diffs.

(Can I convince you to bookmark that page, and use it henceforth when
you want to see some change installed in the repository?)

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sigh...  As mentioned several times before, please go to
>
>   https://git.savannah.gnu.org/cgit/emacs.git
>
> Click on "emacs-27", find my change from a few hours ago, click on its
> line, and you will see the diffs.

Good advice, but this reminds me of something that occurred to me some
time ago: Perhaps it would be nice if the script that sends out diff
emails also looked for text in the commit message that says "bug#4242"
and then Cc's 4242@debbugs.gnu.org?

It would be especially useful when doing bug triage on reopened bug
reports, where you could see what the patch applied was without going on
an archaeological expedition into git log, but also generally more
friendly towards bug reporters, who could then see the patch immediately
themselves.

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Drew Adams <drew.adams@oracle.com>,  43569@debbugs.gnu.org,
>   juri@linkov.net
> Date: Sat, 26 Sep 2020 17:45:21 +0200
> 
> Good advice, but this reminds me of something that occurred to me some
> time ago: Perhaps it would be nice if the script that sends out diff
> emails also looked for text in the commit message that says "bug#4242"
> and then Cc's 4242@debbugs.gnu.org?

I don't think I want to get patches in my mailbox twice.  There's
emacs-diffs for that purpose.

> It would be especially useful when doing bug triage on reopened bug
> reports, where you could see what the patch applied was without going on
> an archaeological expedition into git log

But that's just one Git command away...

> but also generally more friendly towards bug reporters, who could
> then see the patch immediately themselves.

Only if they are subscribed to the bug list, no?

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> but also generally more friendly towards bug reporters, who could
>> then see the patch immediately themselves.
>
> Only if they are subscribed to the bug list, no?

I thought the bug reporter got a copy of all mail to the
@debbugs.gnu.org address?  Hm.  But...  come to think of it, they don't
do, they?

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: drew.adams@oracle.com,  43569@debbugs.gnu.org,  juri@linkov.net
> Date: Sat, 26 Sep 2020 18:13:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> but also generally more friendly towards bug reporters, who could
> >> then see the patch immediately themselves.
> >
> > Only if they are subscribed to the bug list, no?
> 
> I thought the bug reporter got a copy of all mail to the
> @debbugs.gnu.org address?  Hm.  But...  come to think of it, they don't
> do, they?

Not unless there's some magic on debbugs.  They get the message which
closes a bug, but I don't think they automatically get other messages,
unless they are CC'ed.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > > You can see the code via the Git Web interface offered by Savannah's
> > > Emacs page.  I provided a link several times in the past.
> >
> > If you post something here that I can use to
> > replace the :enable code I showed, I'll be
> > glad to try that and let you know what I see.
> 
> Sigh...  As mentioned several times before, please go to...
> Click on "emacs-27", find my change from a few hours ago, click on its
> line, and you will see the diffs.
> (Can I convince you to bookmark that page, and use it henceforth when
> you want to see some change installed in the repository?)

I think we're miscommunicating.  I didn't ask
to see your patch (diff).

I said that if you post here code I can use
to replace the :enable code I showed then I'll
be glad to help out by trying it and letting
you know what I see.  If you don't want to do
that, fine.

And thanks for patching, assuming the result
takes care of the problem discussed.  In that
case, when Emacs releases again (27.2?), with
the patch applied, Emacs will no longer present
the reported regression - the same :enable
will work for all Emacs releases (except 27.1).

In that case, the :enable condition will become:

(or (version= "27.1" emacs-version) ; bug #43569
    (not (condition-case nil
             (tags-loop-eval tags-loop-scan)
           (error t))))

so that the menu item is still enabled
unconditionally for the (presumably still)
broken 27.1.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 09:31:43 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> > Sigh...  As mentioned several times before, please go to...
> > Click on "emacs-27", find my change from a few hours ago, click on its
> > line, and you will see the diffs.
> > (Can I convince you to bookmark that page, and use it henceforth when
> > you want to see some change installed in the repository?)
> 
> I think we're miscommunicating.  I didn't ask
> to see your patch (diff).
> 
> I said that if you post here code I can use
> to replace the :enable code I showed then I'll
> be glad to help out by trying it and letting
> you know what I see.  If you don't want to do
> that, fine.

The patch shows the code, doesn't it?  So why do you insist on seeing
the code and not the change?

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Drew Adams <drew.adams@oracle.com>,  43569@debbugs.gnu.org,
>>   juri@linkov.net
>> Date: Sat, 26 Sep 2020 17:45:21 +0200
>> 
>> Good advice, but this reminds me of something that occurred to me some
>> time ago: Perhaps it would be nice if the script that sends out diff
>> emails also looked for text in the commit message that says "bug#4242"
>> and then Cc's 4242@debbugs.gnu.org?
>
> I don't think I want to get patches in my mailbox twice.  There's
> emacs-diffs for that purpose.

Maybe 4242-quiet@debbugs.gnu.org?

Quoth <https://debbugs.gnu.org/Developer.html>:

> If you wish to send a followup message which is not appropriate for
> any mailing list you can do so by sending it to
> nnn-quiet@debbugs.gnu.org or nnn-maintonly@debbugs.gnu.org. Mail to
> nnn-quiet@debbugs.gnu.org is filed in the bug Tracking System but is
> not delivered to any individuals or mailing lists. Mail to
> nnn-maintonly@debbugs.gnu.org is filed in the bug Tracking System and
> is delivered only to the maintainer of the package in question.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  43569@debbugs.gnu.org,
>   juri@linkov.net
> Date: Sat, 26 Sep 2020 20:58:38 +0200
> 
> > I don't think I want to get patches in my mailbox twice.  There's
> > emacs-diffs for that purpose.
> 
> Maybe 4242-quiet@debbugs.gnu.org?
> 
> Quoth <https://debbugs.gnu.org/Developer.html>:
> 
> > If you wish to send a followup message which is not appropriate for
> > any mailing list you can do so by sending it to
> > nnn-quiet@debbugs.gnu.org or nnn-maintonly@debbugs.gnu.org. Mail to
> > nnn-quiet@debbugs.gnu.org is filed in the bug Tracking System but is
> > not delivered to any individuals or mailing lists. Mail to
> > nnn-maintonly@debbugs.gnu.org is filed in the bug Tracking System and
> > is delivered only to the maintainer of the package in question.

That sounds like the direct opposite of what is being saiught here,
doesn't it?

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > I said that if you post here code I can use
> > to replace the :enable code I showed then I'll
> > be glad to help out by trying it and letting
> > you know what I see.  If you don't want to do
> > that, fine.
> 
> The patch shows the code, doesn't it?  So why do you insist on seeing
> the code and not the change?

I didn't insist on anything.  If you want me to help
by trying some alternative :enable code I'm willing
to do that, if you show that :enable code.

If not, that's OK by me.  I'll go with this as a guess:

(or (version= "27.1" emacs-version) ; bug #43569
    (not (condition-case nil
             (tags-loop-eval tags-loop-scan)
           (error t))))

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 12:32:42 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> If not, that's OK by me.  I'll go with this as a guess:
> 
> (or (version= "27.1" emacs-version) ; bug #43569
>     (not (condition-case nil
>              (tags-loop-eval tags-loop-scan)
>            (error t))))

That's not what I've done.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > If you wish to send a followup message which is not appropriate for
>> > any mailing list you can do so by sending it to
>> > nnn-quiet@debbugs.gnu.org or nnn-maintonly@debbugs.gnu.org. Mail to
>> > nnn-quiet@debbugs.gnu.org is filed in the bug Tracking System but is
>> > not delivered to any individuals or mailing lists. Mail to
>> > nnn-maintonly@debbugs.gnu.org is filed in the bug Tracking System and
>> > is delivered only to the maintainer of the package in question.
>
> That sounds like the direct opposite of what is being saiught here,
> doesn't it?

It doesn't help with sending the patch to the bug reporter, but it does
fix the problem of stashing a copy of the patch in the bug tracker (and
not annoying anybody when doing so), though.

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> That's not what I've done.

OK, I've looked at your patch; thx.  And I've updated
my code.  For Emacs < 27, I've found that there's no
good condition for :enable.  I was mistaken thinking
that (tags-loop-eval tags-loop-scan) could be used.
___

FWIW:

I call the menu item for [tags-repl-continue]
"Continue Search/Replace", with :help "Continue last
tags search or replace operation".

It's incorrect to say that it continues the last tags
replace operation.  It continues the last tags search
or replace operation.  If the last tags operation was 
`tags-search' and not `tags-query-replace', then it
continues the last search, not the last replace.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 18:17:26 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> I call the menu item for [tags-repl-continue]
> "Continue Search/Replace", with :help "Continue last
> tags search or replace operation".
> 
> It's incorrect to say that it continues the last tags
> replace operation.  It continues the last tags search
> or replace operation.  If the last tags operation was 
> `tags-search' and not `tags-query-replace', then it
> continues the last search, not the last replace.

That is factually correct, but I think the current menus are less
confusing to newbies than your proposal.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > If you wish to send a followup message which is not appropriate for
>>> > any mailing list you can do so by sending it to
>>> > nnn-quiet@debbugs.gnu.org or nnn-maintonly@debbugs.gnu.org. Mail to
>>> > nnn-quiet@debbugs.gnu.org is filed in the bug Tracking System but is
>>> > not delivered to any individuals or mailing lists. Mail to
>>> > nnn-maintonly@debbugs.gnu.org is filed in the bug Tracking System and
>>> > is delivered only to the maintainer of the package in question.
>>
>> That sounds like the direct opposite of what is being saiught here,
>> doesn't it?
>
> It doesn't help with sending the patch to the bug reporter, but it does
> fix the problem of stashing a copy of the patch in the bug tracker (and
> not annoying anybody when doing so), though.

Yes, that's the issue I was thinking about (sorry for not being explicit
enough, I counted on my selective quoting to do the work for me).

FWIW this feature (having the BTS record what patches were applied in
the context of a specific report) is a thing other forges do.

I can't speak for the maintainers of projects hosted on these forges,
but I can imagine it being handy: sure, finding all commits referencing
a bug ID is "just one Git command away", but that can mean a couple of
seconds twiddling one's thumbs while the disk spins; having that
information readily displayed in the thread sounds like a timesaver.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I can't speak for the maintainers of projects hosted on these forges,
> but I can imagine it being handy: sure, finding all commits referencing
> a bug ID is "just one Git command away", but that can mean a couple of
> seconds twiddling one's thumbs while the disk spins; having that
> information readily displayed in the thread sounds like a timesaver.

It also helps the people who are looking at the web interface -- the
patch that resolves the bug report would be there, which I often find
helpful when looking at problems in other systems.

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Dmitry Gutov]

On 27.09.2020 15:17, Lars Ingebrigtsen wrote:
> It also helps the people who are looking at the web interface -- the
> patch that resolves the bug report would be there, which I often find
> helpful when looking at problems in other systems.

It could also be an HTTP URL instead of the patch itself, if we wanted 
to avoid duplication.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 27.09.2020 15:17, Lars Ingebrigtsen wrote:
>> It also helps the people who are looking at the web interface -- the
>> patch that resolves the bug report would be there, which I often find
>> helpful when looking at problems in other systems.
>
> It could also be an HTTP URL instead of the patch itself, if we wanted
> to avoid duplication.

I'd prefer the patch itself -- systems come and go, and URLs don't last.

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > I call the menu item for [tags-repl-continue]
> > "Continue Search/Replace", with :help "Continue last
> > tags search or replace operation".
> >
> > It's incorrect to say that it continues the last tags
> > replace operation.  It continues the last tags search
> > or replace operation.  If the last tags operation was
> > `tags-search' and not `tags-query-replace', then it
> > continues the last search, not the last replace.
> 
> That is factually correct, but I think the current menus
> confusing to newbies than your proposal are less.

I won't argue about it, but I think that as soon as a
user tries tags-searching and then tries to go back to
continue a tags query-replace, s?he will be mightily
surprised.  Likewise, trying to go back to continue a
tags search after having last done a tags query-replace.

That's exactly how I discovered this.

If we had separate "continue" commands, at least from
the menus, then this wouldn't be a gotcha.

I do agree that simply having a menu item or help echo
that refers to continuing the last search or replace is
hardly the best remedy.  It would be good, I think, for
some remedy to be applied.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Eli Zaretskii]

> Date: Sun, 27 Sep 2020 12:10:50 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 43569@debbugs.gnu.org
> 
> > > I call the menu item for [tags-repl-continue]
> > > "Continue Search/Replace", with :help "Continue last
> > > tags search or replace operation".
> > >
> > > It's incorrect to say that it continues the last tags
> > > replace operation.  It continues the last tags search
> > > or replace operation.  If the last tags operation was
> > > `tags-search' and not `tags-query-replace', then it
> > > continues the last search, not the last replace.
> > 
> > That is factually correct, but I think the current menus
> > confusing to newbies than your proposal are less.
> 
> I won't argue about it, but I think that as soon as a
> user tries tags-searching and then tries to go back to
> continue a tags query-replace, s?he will be mightily
> surprised.

Like I said: factually correct, but there's no reason for the user to
do something like that, except by accident.

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Drew Adams]

> > > > I call the menu item for [tags-repl-continue]
> > > > "Continue Search/Replace", with :help "Continue last
> > > > tags search or replace operation".
> > > >
> > > > It's incorrect to say that it continues the last tags
> > > > replace operation.  It continues the last tags search
> > > > or replace operation.  If the last tags operation was
> > > > `tags-search' and not `tags-query-replace', then it
> > > > continues the last search, not the last replace.
> > >
> > > That is factually correct, but I think the current menus
> > > confusing to newbies than your proposal are less.
> >
> > I won't argue about it, but I think that as soon as a
> > user tries tags-searching and then tries to go back to
> > continue a tags query-replace, s?he will be mightily
> > surprised.
> 
> Like I said: factually correct, but there's no reason
> for the user to do something like that, except by accident.

FWIW (so please don't claim I'm "insisting" or arguing) -

Like I said:

   That's exactly how I discovered this.

I didn't do it by accident.  Someone can easily do
both tags searching and tags query-replacing, moving
from one to the other.

Clearest (at least for menu purposes) would for there
to be two separate continue commands - continue last
search and continue last query-replace.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 43308@debbugs.gnu.org, Eli Zaretskii <eliz@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.

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

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

bug#43569: 28.0.50; Menu "Continue Tags Search" signals an error

[Lars Ingebrigtsen]

Skimming this thread, there doesn't seem to be anything further to do
here, and I'm closing this bug report.

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