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.