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