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