From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc. Date: Wed, 16 Mar 2022 20:56:16 +0200 Organization: LINKOV.NET Message-ID: <861qz1zqfb.fsf@mail.linkov.net> References: <87sftyweb2.fsf@gmail.com> <861r1iyrvw.fsf@mail.linkov.net> <87zgo6owaf.fsf@gmail.com> <86k0f9xnrn.fsf@mail.linkov.net> <87tuedp6pl.fsf@gmail.com> <861r1g7n3b.fsf@mail.linkov.net> <87o84jcx5x.fsf@gmail.com> <8635lvif0r.fsf@mail.linkov.net> <87mtidip1w.fsf@gmail.com> <86zglrl4gq.fsf@mail.linkov.net> <87ee32yk7v.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11110"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: 53126@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 16 20:06:29 2022 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 1nUYya-0002kC-Fw for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Mar 2022 20:06:28 +0100 Original-Received: from localhost ([::1]:50414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nUYyY-0002T3-Oq for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Mar 2022 15:06:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nUYxD-00022C-L6 for bug-gnu-emacs@gnu.org; Wed, 16 Mar 2022 15:05:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nUYxB-0002IB-SW for bug-gnu-emacs@gnu.org; Wed, 16 Mar 2022 15:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nUYxB-0001vg-Jn for bug-gnu-emacs@gnu.org; Wed, 16 Mar 2022 15:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Mar 2022 19:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53126 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 53126-submit@debbugs.gnu.org id=B53126.16474574647349 (code B ref 53126); Wed, 16 Mar 2022 19:05:01 +0000 Original-Received: (at 53126) by debbugs.gnu.org; 16 Mar 2022 19:04:24 +0000 Original-Received: from localhost ([127.0.0.1]:52309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUYwZ-0001uM-8G for submit@debbugs.gnu.org; Wed, 16 Mar 2022 15:04:23 -0400 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]:35091) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUYwW-0001u5-JO for 53126@debbugs.gnu.org; Wed, 16 Mar 2022 15:04:21 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id C24DC240003; Wed, 16 Mar 2022 19:04:12 +0000 (UTC) In-Reply-To: <87ee32yk7v.fsf@gmail.com> (Augusto Stoffel's message of "Tue, 15 Mar 2022 22:33:24 +0100") 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:228446 Archived-At: >> So I don't see the need to have this line: >> >> (remove-hook 'minibuffer-setup-hook #'minibuffer-lazy-highlight-setup) > > Okay, but if I remove this line, then all calls to > minibuffer-lazy-highlight-setup will require a with-minibuffer-setup > hook. And this will be awkward: > > (minibuffer-with-setup-hook (if isearch-lazy-highlight > #'minibuffer-lazy-highlight-setup > #'ignore) > (read-from-minibuffer "Something: ")) The answer depends on another question: how do you intend the users would enable this feature? When to enable it in all minibuffers (like e.g. minibuffer-depth-indicate-mode does) the users will add to their init files: (add-hook 'minibuffer-setup-hook #'minibuffer-lazy-highlight-setup) Then removing the user's customization would not be a nice thing to do. OTOH, minibuffer-with-setup-hook will remove only own hook, not the user's one. So to allow enabling this feature selectively, minibuffer-with-setup-hook is not quite awkward. >> BTW, what is the relation between the minibuffer-lazy-highlight feature >> and another proposed feature that immediately updates the search in >> the buffer while editing the string in the minibuffer by isearch-edit-string? >> Can minibuffer-lazy-highlight be considered as a lightweight version of >> the buffer search from the minibuffer? > > Well, there's a package for that on ELPA (isearch-mb), so extending > isearch-edit-string to do that seems superfluous now? It's still possible to add this feature to isearch-edit-string, when the change would not be too enormous. I recall squeezing it into a small patch, but unfortunately it requires changes in keymap priorities. >>> There are a few more we could add (perhaps later), >>> such as `occur' and `keep-lines'. >> >> I tried (add-hook 'minibuffer-setup-hook #'minibuffer-lazy-highlight-setup) >> in the minibuffer of 'occur' and others, and it works nicely. >> Maybe it could even semi-deprecate the package re-builder.el. >> >> Thanks for this generally usable feature. > > By the way, this is a byproduct of that long discussion that led to > isearch-mb, so it was not all in vain :-). Are you sure these features can't be combined? One feature basically runs isearch-search-and-update in the buffer from the minibuffer, and this feature runs isearch-lazy-highlight-new-loop. >>> - There's no customization variable to enable the minibuffer lazy >>> highlight. The rationale is that each command that will use it should >>> define its own user option (or use an existing one). For >>> `isearch-edit-string' it's `isearch-lazy-highlight'; for >>> `query-replace' it's `query-replace-lazy-highlight'; and so on. >> >> A common customizable option to enable this everywhere would be nice too. >> Maybe disabling is already possible by customizing >> 'minibuffer-lazy-count-format' to nil? Then the checks for >> non-nil 'minibuffer-lazy-count-format' could be added to >> more places, such as to wrap the whole '(condition-case error' >> in query-replace-read-args with the 'when' condition, etc. > > Yes, the user can set minibuffer-lazy-count-format to nil to get rid of > the lazy count. > > Concerning query-replace, why would anyone want to have lazy highlight > during the perform-replace loop, but not earlier? I'm not a fan of > adding a custom option here, not because it would be hard, but because > it seems totally unnecessary. Maybe a new option would make sense for the same reason why there is the option isearch-lazy-count?