From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#43308: 28.0.50; Improvements to Edit->Search menu Date: Thu, 10 Sep 2020 08:38:04 -0700 Message-ID: References: <87zh5xiuk4.fsf@localhost> <831rj9k79b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29940"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43308@debbugs.gnu.org To: Eli Zaretskii , Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 10 17:39:08 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 1kGOfE-0007fY-Cl for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Sep 2020 17:39:08 +0200 Original-Received: from localhost ([::1]:42588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGOfD-0006QG-DH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Sep 2020 11:39:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGOf8-0006Pv-70 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2020 11:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57649) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGOf7-00020x-UI for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2020 11:39:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kGOf7-0006nU-R8 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2020 11:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Sep 2020 15:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43308 X-GNU-PR-Package: emacs Original-Received: via spool by 43308-submit@debbugs.gnu.org id=B43308.159975229226071 (code B ref 43308); Thu, 10 Sep 2020 15:39:01 +0000 Original-Received: (at 43308) by debbugs.gnu.org; 10 Sep 2020 15:38:12 +0000 Original-Received: from localhost ([127.0.0.1]:40962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGOeK-0006mQ-67 for submit@debbugs.gnu.org; Thu, 10 Sep 2020 11:38:12 -0400 Original-Received: from mail-ej1-f48.google.com ([209.85.218.48]:37527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGOeI-0006mD-SE for 43308@debbugs.gnu.org; Thu, 10 Sep 2020 11:38:11 -0400 Original-Received: by mail-ej1-f48.google.com with SMTP id nw23so9376562ejb.4 for <43308@debbugs.gnu.org>; Thu, 10 Sep 2020 08:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Ur5g8Iyn7NzR7557wb9MEeR0muXTtz7QpmsNFnYeCcc=; b=Yv9VjRL/XHklDSFVo0dbQ/Gi5nUE/ts7SZ1ZMsbAEt83v2RbPg4zWR3d3plo9eRkdT yEs+ZHGZecClWTRX/WuFHokje/Qf6CX2NOfYhGiQOG5VJNcLhP4UPRb7jivxIe8/Z7Dm IP6mb4mD2+o+msfGK2DrxU/oiqNx8XauEgZ32TKoQVudsQPn+2DcqF+4Ivc4pAEX8kNy e1uAmjV5wbyLzbXe9JcmRAQ9IY+6sS5FCVZ2oh8L5Jl8w/ySHeok0pRgaGNr7T0KnqOv 8geS06DC7AJDkSmbRIbyu23xIfmlp+pT9TYAFcXIMN+nsqmSRF9obPsAhGTxorDwBm9y uMgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Ur5g8Iyn7NzR7557wb9MEeR0muXTtz7QpmsNFnYeCcc=; b=NNEPVU9c4w96F3ugB0HjIeLaxh+L+/RNdCdeLa2ueNLi1ngUaBO8dS2U1gSc/G+jb3 F0KwPOKO9oBxNoHt585MP8d1rMrdWZnSTWarXExifDgOQWwXPtwxo9v3Gq+S+UdtXjHF +x9oE96IB7dGb0KnaN5Vj8zlznB+QETptrQjLKROSsj9Xom0imJhyT4xT3dCccWnuiw2 /YaPIjz2cLR1O+NV9V6hlRsA3e/2d2/AdVGOsfhfu1825GwuMil9mBkqqJzmWJY+u0UZ 9Taw4CnUrsIaOoIzEHHUGyM4s405nS3Ay8KwBvwZAzt2Q/cIRAsYjCesfMoQVN7xkfMo 5Y7w== X-Gm-Message-State: AOAM533npcHvNGW8v8KA1uRxu1h7T8yjlo62HX40TMNNI/ppXHx8r03p i3HZoheN355b45JDoFjS5IcIFpRYHlvs3eun/h4= X-Google-Smtp-Source: ABdhPJyxMQuUJMQtvoju121Nffnl6R519DHDQx9VM3ZrGbLjc8AimPeeZiX7wZdrmzAf5kzhOFwY3VT4D+l+7E5z2JQ= X-Received: by 2002:a17:906:1b15:: with SMTP id o21mr9237904ejg.377.1599752284790; Thu, 10 Sep 2020 08:38:04 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 10 Sep 2020 08:38:04 -0700 In-Reply-To: <831rj9k79b.fsf@gnu.org> 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:187741 Archived-At: Eli Zaretskii 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"?