From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc. Date: Tue, 15 Mar 2022 22:33:24 +0100 Message-ID: <87ee32yk7v.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15479"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: 53126@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 15 22:34:11 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 1nUEny-0003oL-Ul for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Mar 2022 22:34:11 +0100 Original-Received: from localhost ([::1]:57024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nUEnx-0004GJ-Cd for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Mar 2022 17:34:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nUEnq-0004Fw-No for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 17:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nUEnq-00081j-Ex for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 17:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nUEnq-0003aU-6F for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 17:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Mar 2022 21:34:02 +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.164738001413751 (code B ref 53126); Tue, 15 Mar 2022 21:34:02 +0000 Original-Received: (at 53126) by debbugs.gnu.org; 15 Mar 2022 21:33:34 +0000 Original-Received: from localhost ([127.0.0.1]:49715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUEnO-0003Zj-Et for submit@debbugs.gnu.org; Tue, 15 Mar 2022 17:33:34 -0400 Original-Received: from mail-ej1-f46.google.com ([209.85.218.46]:47063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUEnM-0003ZV-9V for 53126@debbugs.gnu.org; Tue, 15 Mar 2022 17:33:32 -0400 Original-Received: by mail-ej1-f46.google.com with SMTP id qx21so288699ejb.13 for <53126@debbugs.gnu.org>; Tue, 15 Mar 2022 14:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=w+3qdGfMt5dYL6wFfT4VwFG0sn8lMJdDKj7dx8aop3Q=; b=gBxcHZh0FtRSbKcXim+rYnjx061AQ5MfAiAUmUBuAAELvOzLnaxPypYmezEpiUSm5w un+6xUV4ZjGcnRfQGrMS2OC48aKaEMdGGjW+PuxD7hIt3ZdhCyajC4t33LocggeaGK4J gzMvdfgrJU3ruEXk6R4rKetZTGQf2/wgJnmbYGuF+1PiSRsCSBqht8iAyRpvcRwBIwaq vO51wDq9/hleY47xFVzZd4kJXBPvmJwgFcDkBqLT4MYC39F++m7DJ3NTcDd/2DwdDgMY Q0WrL8tiFov71XntWYmH7CMXllDDSSwlZ2qWETdpmdDEp7wYhcTPjxFmvxLtB5oG7db7 ZDvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=w+3qdGfMt5dYL6wFfT4VwFG0sn8lMJdDKj7dx8aop3Q=; b=hT4cSJeuIcS+TK6fVxktpSRt/jiuOcuyqDTVTlS5k9HI1cn70Z8XPAEkk+N+FIh75v K1DjMM3+q3yxqn7JcA+6vxYXd1ThyIdgge55WEj1HbmCDwvixJdB3/axJC9sNTSp86ZK sCHGuyxmvHb1xYwsA6Pa+v84Io+QDSaVmYQ6yrVuS6ksmHrnArSE2lRRJr+zJI/zt9hc ltGEdd8O0PMeygbJfYXMX+CWvHfFOVskqYh81D25j9UIKukVfAob/ZZ/F0dPADQfow7n QSObvRI4aF5HiqFnNW43Tu42Giqlci/MmzMhXGMWfu6J/Epe9JR+7jA/eQZd2YhxGlb8 jQJw== X-Gm-Message-State: AOAM531/qbSSH4fhVpifFUzLnMqYYyzClrfpXxoF4Pvj02tI9Um7hTv4 eb6Y1i9atR1C9T/5FrRFChTgKD/fhS0= X-Google-Smtp-Source: ABdhPJyoWGLsiAOnk8HJgFxh4wTAntVmMljM1WdZxltoasPiyl28Wzl+5VHLh1aC1V7jDchK92gtHg== X-Received: by 2002:a17:907:6d0e:b0:6d7:c85:5bf5 with SMTP id sa14-20020a1709076d0e00b006d70c855bf5mr24419229ejc.31.1647380006015; Tue, 15 Mar 2022 14:33:26 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::758e]) by smtp.gmail.com with ESMTPSA id ne42-20020a1709077baa00b006d76251f4e7sm74156ejc.109.2022.03.15.14.33.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Mar 2022 14:33:25 -0700 (PDT) In-Reply-To: <86zglrl4gq.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 15 Mar 2022 19:09:49 +0200") 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:228423 Archived-At: On Tue, 15 Mar 2022 at 19:09, Juri Linkov wrote: >> Inlined below some further comments. >> >>>>> I meant using simply >>>>> >>>>> (add-hook 'minibuffer-setup-hook 'isearch-read-with-highlight-setup) >>>>> >>>>> But it seems isearch-read-with-highlight-setup doesn't set >>>>> isearch-lazy-count-display-function. >> >> What used to be 'isearch-read-with-highlight-setup' is now >> 'minibuffer-lazy-highlight-setup'. >> >> Just to make sure I understood you: your suggestion is for this function >> to remove itself automagically from the minibuffer setup hook, to >> dispense with the need of 'minibuffer-with-setup-hook'? This seems >> handy but unusual, hence my question. >> ... >> - In a previous message, you seemed to suggest making >> `minibuffer-lazy-highlight-setup' self-cleaning form the >> minibuffer-setup-hook, so as to dispense with the need for >> `with-minibuffer-setup-hook'. I did exactly that, but since I haven't >> seen this convention before, I wanted to double check. > > Actually, my comment was about having the line that you already added > in your latest patch in 'minibuffer-lazy-highlight-setup': > > (add-hook 'lazy-count-update-hook #'minibuffer-lazy-highlight--count) > > 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: ")) > Also I noticed that you changed the function 'isearch-lazy-count-display-function' > to the hook 'lazy-count-update-hook', and this looks fine, > I see no problem with this. > >> - Besides query-replace, I only added lazy highlight to >> isearch-edit-string for now. > > 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? >> 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 :-). >> - 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. >> - As to the lazy count during `perform-replace': I would like to leave >> this for later. In fact, I think the lazy highlight has some issues >> that need fixing beforehand. For instance, if I replace "a" with >> "aba", then the "a"'s from the replacement text also get lazy >> highlighted. We shouldn't refresh the lazy highlight during >> `preform-replace'. Then adding lazy count on top should be easy. > > Patches welcome. > >>>> I guess this could be done. >>> >>> Maybe two separate hooks could be defined? One highlights like >>> lazy-highlight, and another counts like lazy-count does: >>> >>> (add-hook 'minibuffer-setup-hook 'isearch-read-with-highlight-setup) >>> (add-hook 'minibuffer-setup-hook 'isearch-read-with-count-setup) >> >> The highlight without counting can be achieved by binding a suitable new >> variable. Counting without highlight is not supported by isearch AFAIU. > > Counting without highlighting is only possible by redefining the function > 'isearch-lazy-highlight-match' to a no-op function.