From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#43308: 28.0.50; Improvements to Edit->Search menu Date: Sun, 20 Sep 2020 11:10:19 +0300 Message-ID: <83bli027is.fsf@gnu.org> References: <87zh5xiuk4.fsf@localhost> <831rj9k79b.fsf@gnu.org> <83sgbpiqa7.fsf@gnu.org> <87mu1xa380.fsf@mail.linkov.net> <83imclii71.fsf@gnu.org> <87wo1178cn.fsf@mail.linkov.net> <83d02tifi3.fsf@gnu.org> <87ft7cx6kh.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24142"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43308@debbugs.gnu.org, stefankangas@gmail.com, juri@linkov.net To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 20 10:11:10 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 1kJuRC-0006BM-7K for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Sep 2020 10:11:10 +0200 Original-Received: from localhost ([::1]:49708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJuRA-0000cX-SR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Sep 2020 04:11:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJuR4-0000cD-NP for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 04:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37065) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJuR4-0002un-DD for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 04:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kJuR4-0000Ra-8O for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 04:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Sep 2020 08:11:02 +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.16005894371672 (code B ref 43308); Sun, 20 Sep 2020 08:11:02 +0000 Original-Received: (at 43308) by debbugs.gnu.org; 20 Sep 2020 08:10:37 +0000 Original-Received: from localhost ([127.0.0.1]:48611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJuQf-0000Qt-Dd for submit@debbugs.gnu.org; Sun, 20 Sep 2020 04:10:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJuQZ-0000Qe-VC for 43308@debbugs.gnu.org; Sun, 20 Sep 2020 04:10:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60003) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJuQU-0002lQ-46; Sun, 20 Sep 2020 04:10:26 -0400 Original-Received: from [176.228.60.248] (port=3627 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJuQP-0001Ib-BB; Sun, 20 Sep 2020 04:10:25 -0400 In-Reply-To: <87ft7cx6kh.fsf@localhost> (message from Ihor Radchenko on Sun, 20 Sep 2020 15:15:10 +0800) 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:188459 Archived-At: > From: Ihor Radchenko > 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.