GNU bug report logs - #43308
28.0.50; Improvements to Edit->Search menu

Previous Next

Full log

Message #17 received at 43308 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43308 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#43308: 28.0.50; Improvements to Edit->Search menu
Date: Thu, 10 Sep 2020 09:19:05 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.