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

[Eli Zaretskii <eliz@gnu.org>]

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