From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#43308: 28.0.50; Improvements to Edit->Search menu Date: Sun, 13 Sep 2020 18:08:47 +0800 Message-ID: <87r1r6at00.fsf@localhost> References: <87zh5xiuk4.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17313"; mail-complaints-to="usenet@ciao.gmane.io" To: 43308@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 13 12:10:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kHOxW-0004ME-Mc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Sep 2020 12:10:10 +0200 Original-Received: from localhost ([::1]:51110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kHOxV-0004QE-MH for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Sep 2020 06:10:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHOxO-0004Q6-Gz for bug-gnu-emacs@gnu.org; Sun, 13 Sep 2020 06:10:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kHOxO-0002WB-82 for bug-gnu-emacs@gnu.org; Sun, 13 Sep 2020 06:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kHOxO-0007QC-0a for bug-gnu-emacs@gnu.org; Sun, 13 Sep 2020 06:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Sep 2020 10:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43308 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.159999179728514 (code B ref -1); Sun, 13 Sep 2020 10:10:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 13 Sep 2020 10:09:57 +0000 Original-Received: from localhost ([127.0.0.1]:49531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHOxI-0007Pp-IH for submit@debbugs.gnu.org; Sun, 13 Sep 2020 06:09:57 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:45772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHOxG-0007Pg-5H for submit@debbugs.gnu.org; Sun, 13 Sep 2020 06:09:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHOxG-0004Pn-0X for bug-gnu-emacs@gnu.org; Sun, 13 Sep 2020 06:09:54 -0400 Original-Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:38902) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kHOxD-0002UT-C8 for bug-gnu-emacs@gnu.org; Sun, 13 Sep 2020 06:09:53 -0400 Original-Received: by mail-pf1-x433.google.com with SMTP id l126so10211624pfd.5 for ; Sun, 13 Sep 2020 03:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=n8OVxHBWStpVjZQIu0ntW8IgJa+2B7Tp25HteUXkCwA=; b=rH48z9i06B01jXU1v2c25eh/bupessjS3mXiTgRmhRuFtVMnoMV6ntBsui7jug9Won WduNg3U0b7u8hCfyp8bQWW/5bPgH7VRCmz/TOrVJZwto0QsSuStsrucWayAVOJ7mBEt7 ebi/0rLaiNNaTk44+gQc/VA5ULjxWk5lFc5tu84oBzJyEcdYHGSQxyrVDmnK4HiRM+eI Po5OBjccfEae+0LIOGJZA0RbWpaUW23zG7yAL5jKBVjTM99iOJOPfoHaA4qVgFI2vZhZ 6JmC/8rlbA8OAjIz975vmOoIfSrlJc/U9KjMoMUO9PCC4sjpCsUbcUnWy68++sWhXode tozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=n8OVxHBWStpVjZQIu0ntW8IgJa+2B7Tp25HteUXkCwA=; b=FCS4fQF27GiYirE5bT4BxWLdeieOe7PPLH4yeqASgF98ifXYccJGx73QpF+EmBjHsr b0r613xDXUtSigLDmKdhtyzMTYJnpED+cDeD3ZqjzL6k+LTNjTu5S0AwMxAEjDJH029O i8XsHfaoNPlD1OsYuKWAB485Pa1Ob1mjPmUEdaHtSTRKC9akE/VNiOmQ/k5i1SF/+9zq IluFlDVjqR+UG//9i7rTY/GWNUU8zx2bdSFnx4R4wJwleIAaW7iG72+EQ40yzgAbS70d ELviv/6djCs0H6fMvq4R4LKR6com6r7CKmTJBktaCBjv4aIP1cXezeJo3st9vKfk616+ Gurw== X-Gm-Message-State: AOAM531Yw4JWsELtP4ybZ5ER0aw8lQiIimWzdo51r24Sg8PgJq7MzFMY qJHNmKbDAucJVcdJTsIbaINiiBsRJAxqtU5g X-Google-Smtp-Source: ABdhPJwMJi9GPA80iYkcl6C4etwhsf4rrTKzyV2rJHcd7FhkFcxPlxO33+E6mWmtGLJRP8FfvEEa8w== X-Received: by 2002:a63:de56:: with SMTP id y22mr7514959pgi.166.1599991788418; Sun, 13 Sep 2020 03:09:48 -0700 (PDT) Original-Received: from localhost ([210.3.160.230]) by smtp.gmail.com with ESMTPSA id x140sm7134916pfc.211.2020.09.13.03.09.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Sep 2020 03:09:47 -0700 (PDT) In-Reply-To: <87zh5xiuk4.fsf@localhost> Received-SPF: pass client-ip=2607:f8b0:4864:20::433; envelope-from=yantar92@gmail.com; helo=mail-pf1-x433.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:187924 Archived-At: It seems that the opinions are a bit split here, so I am try to summarise the current state of the discussion in this message and refine my suggestions from original bug report. 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. Target users: 1. Menu is designed for users unfamiliar with Emacs concepts 2. Moreover, we do not expect those users to read Emacs manual or even tutorial 3. All the users are expected to know functionality, which is common among modern editor apps 4. Menu does not try to show all possible functionality of Emacs, just the most important (otherwise, people will be lost in too many menu items) The aims of the menu: 1. Show people Emacs equivalents text editing functions they would expect to use from other editors 2. Provide an indication how to switch to Emacs-specific commands (by indicating key bindings and command help) 3. Provide the most important Emacs-specific commands, which can be useful even though they have no equivalent in other editors Now, let me go through my original proposal and put in into the context of the above principles, while taking into account the comments on this bug report. ---------- 1. Replacing non-interactive search by interactive search ---------- There seems to be controversy on this part of the proposal: Eli Zaretskii (Thu. 22:59) > 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. Stefan Kangas (Thu. 23:38) replying to previous message > 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. Eli Zaretskii (Thu. 23:51) replying to previous message >> 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. Stefan Kangas (Fri. 00:19) replying to previous message >> 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. Eli Zaretskii (Fri. 00:30) replying to previous message > > > 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. > > And, btw, their incremental search works subtly differently: once you > click the Next or Previous button, typing characters doesn't > necessarily modify the search string, you need to click in the search > field for that. > > So even if the user has some experience with these browsers, they > won't necessarily feel at home with Emacs's Isearch. > > > 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. My reply: The above comment that incremental search may be unfamiliar is a valid concern. However, non-interactive search is not commonly used in Emacs by people who get some minimal experience (correct me if I am wrong). We are promoting the command that may be relatively easy to used for the user, but it does not help the user to learn the more common and powerful Emacs equivalent (which is isearch). As Stefan Kangas mentioned, we can expect that users are somehow familiar with incremental search concept from browsers. People unfamiliar with browsers are very uncommon case - if we start to consider all such possibilities, menu will grow into duplicate of custom interface (in terms to overly too many features). 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. They have to go to menu->edit->search->repeat forward/backwards. On the contrary, isearch does provide forward/backward search buttons at least (though they are located far from the entered search string - in the toolbar). I would argue that isearch does a better (not ideal though) job creating familiar interface. Therefore, I would favour isearch over the non-interactive version. ----------- 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. Eli Zaretskii (Thu. 22:59) > > 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. Stefan Kangas (Thu. 23:38) replying to previous message > >> 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. Eli Zaretskii (Thu. 23:51) replying to previous comment > > > 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? My reply: 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. In the case of Emacs, that would mean showing prev/next match toolbar buttons right above the minibuffer. 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). I believe that the same functionality can be implemented for non-interactive search - we can reuse the same toolbar as in isearch. Moreover, having prev/next match buttons will effectively provide the following separate menu items in a single search command (or maybe in two commands for forward/backward search): - Edit->Search menu->String Forward - Edit->Search menu->String Backwards - Edit->Search menu->Regexp Forward - Edit->Search menu->Regexp Backwards - Edit->Search menu->Repeat Forward - Edit->Search menu->Repeat Backwards Same with isearch, I believe that the toolbar position would better be right above the minibuffer. On the flickering issue: Does it exist with the current toolbar for isearch? If there no bug reports on it, it is probably just hypothetical and we should not care about it. ---------- 3. Renaming Forward/Backward string to Search forward/backward ---------- Eli Zaretskii (Thu. 22:59) > > 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? Stefan Kangas (Thu. 23:38) replying to previous message > > 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".) My reply: No space will be wasted when renaming "Forward/Backward string" to "Search forward/backward". The char count is the same. But, as I said we add an extra benefit of not using word that is potentially confusing for non-programmers. ------ 4. Unfamiliar "Search tagged files..." command and other menu items, that user is not familiar with (yet) ------ Eli Zaretskii (Thu. 22:59) > > 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. > > I tried to click it, got a prompt about regex, then prompt about tag > > table (what is it?). Finally, I got error "File ~/TAGS does not > > exist". This made me recall vague memory about Emacs manual talking > > about some kind of completion feature for large code projects - > > something I never used. > > Did you try "C-h k" before selecting that? This would display the > documentation of that command. It's a canonical way of learning about > menu items that don't explain themselves enough at first reading. (Of > course if we can make them more self-explanatory, it's better.) My reply: > Feel free to suggest a better name for the item and/or a better help > string. I cannot suggest a better name since I have no idea how the TAGS functionality works. I just wanted to point out that it was confusing for me. I never had to deal with big multi-file projects where TAGS search is needed. > Did you try "C-h k" before selecting that? This would display the > documentation of that command. It's a canonical way of learning about > menu items that don't explain themselves enough at first reading. (Of > course if we can make them more self-explanatory, it's better.) As you said in another message: > Once again, menus are for those who don't read the documentation, but > just start Emacs and want to do something useful. We cannot expect the user to know about "C-h k". My concrete suggestion is using the tooltip to hint the user how to get more information about the command. The tooltip is already showing a short (yet longer than menu item name) command description. I suggest to add something like "Use mouse-3 (middle click) to get more information" and bind mouse-3 to show help buffer on the command. Best, Ihor Ihor Radchenko writes: > Following up with "Changes for emacs 28" discussion about improving menu > [1] > > Source: http://ergoemacs.org/emacs/modernization_menu.html > > The following menus seems to be more confusing than helpful: > - Edit->Search menu->String Forward > - Edit->Search menu->String Backwards > - Edit->Search menu->Regexp Forward > - Edit->Search menu->Regexp Backwards > - Edit->Search menu->Repeat Forward > - Edit->Search menu->Repeat Backwards > > 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. > > Also, the functionality of the above menu items seems to be strictly > inferior in comparison with isearch items from Edit->Search->Incremental > search sub-menu. The only apparent advantage is that user would not need > to know that moving to next/prev match is C-s/C-r. > > The article suggests to remove the above Search menu items completely > and replace them by incremental search versions. > > I would also add that we can show transient next match/previous match > toolbar icons to assist users, unfamiliar with key bindings. Though need > to make sure that these new toolbar icons can be easily associated with > the search process. For example, we may show additional toolbar at the > bottom (above the mini-buffer isearch prompt) with only these two new > toolbar icons (maybe also "exit search" icon). > > 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". > > Finally, find "Search tagged files..." and the following "Repeat" menu > confusing. What does "tagged files" mean? I tried to click it, got a > prompt about regex, then prompt about tag table (what is it?). Finally, > I got error "File ~/TAGS does not exist". This made me recall vague > memory about Emacs manual talking about some kind of completion feature > for large code projects - something I never used. > > The above is my actual first impression. The menu seems useless for me, > though may have a value for programmers. However, I have two > suggestions: > > 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 > > 2. There is currently no way to understand what some unfamiliar menus do > except blindly trying. As I explained about, it does not always help. > Probably, Emacs could show some kind of tooltip on top of menu items, > explaining what it does in more details. Also, it would be cool to be > able to move to Manual page talking about topic relevant to the menu > item (on right click?). > > Best, > Ihor > > > [1] https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00410.html > > In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) > of 2020-08-15 built on localhost > Repository revision: f712cdbe9e9bdca3d4c7c27e9ac59686ab4c7620 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 > System Description: Gentoo/Linux