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: Thu, 17 Mar 2022 20:10:34 +0100 Message-ID: <87sfrgz979.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> <87ee32yk7v.fsf@gmail.com> <861qz1zqfb.fsf@mail.linkov.net> <875yod1wyb.fsf@gmail.com> <86mtho5y56.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="29589"; 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 Thu Mar 17 20:11:22 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 1nUvWr-0007Sq-QV for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Mar 2022 20:11:21 +0100 Original-Received: from localhost ([::1]:34370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nUvWq-0001AG-7S for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Mar 2022 15:11:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41060) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nUvWY-00017T-EO for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2022 15:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nUvWY-0004w1-5c for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2022 15:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nUvWX-0002qm-Uz for bug-gnu-emacs@gnu.org; Thu, 17 Mar 2022 15:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Mar 2022 19:11: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.164754424410919 (code B ref 53126); Thu, 17 Mar 2022 19:11:01 +0000 Original-Received: (at 53126) by debbugs.gnu.org; 17 Mar 2022 19:10:44 +0000 Original-Received: from localhost ([127.0.0.1]:55214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUvWF-0002q3-KI for submit@debbugs.gnu.org; Thu, 17 Mar 2022 15:10:44 -0400 Original-Received: from mail-ej1-f47.google.com ([209.85.218.47]:43725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUvWD-0002pk-OY for 53126@debbugs.gnu.org; Thu, 17 Mar 2022 15:10:42 -0400 Original-Received: by mail-ej1-f47.google.com with SMTP id d10so12695937eje.10 for <53126@debbugs.gnu.org>; Thu, 17 Mar 2022 12:10:41 -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=6QuUdrSw07IanZ5QGayZDiyMwAysBXvcg/ix+mNJqx4=; b=fepe1ndfaq9wO5Qm3/mAwc6G1oxwtwGCZHLTkRTHxzeQtVpShqmXw/g1Swp4p+Zc4p toBAl5S5vaHJL+97TtBppQV9OlYud2gB+0L2cGxnUXwalmIM4kVm5MbdQDWkq1bXOtJs s6QvNfHSWr/QUdrDt407Dih/ez4bdehTibSdtCICAuDvIPKtWd8HS0IKtWq8RcHg279D HcXF9Y/L+S7l2df6Wc/YYHDpRaR1ZSiUigPQhcoPQGpsgZ7o9uf4FuRQ0memrzOQBItD cAykaO4tAbrx2RZvTYIr9ZK3aFwPmmbcw7fmkHk6LxCoUhQ1ZcDIe8CogifbdmN1BgDv 4cqw== 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=6QuUdrSw07IanZ5QGayZDiyMwAysBXvcg/ix+mNJqx4=; b=QUEBcfshRl81ugMkTLWAI0sGTEOOo/wZGu79iFMUTAARc59fAKaubPpOcAI2faWRyD lbA2LnUU5VI9faHM47rXcpFvEKMQpXhxZ/J+TPSJfj/h0Pzr8zayF9H3CSMjMhlrjz+d Kg+7XaaZtE2N2GIdJiDDsTpLDjtap5wu/JHFhtmk3yrVbxUjC3p3gvbZiFAWzegdKzlf bNM1u3mZckokUGqH3256Lt8tYlqErcd2TyceNpHszMwSsS9kaE5RrobhQ6g8ESXUypm2 aPMyUj33wjXcwd9H+mOsb8riPXe+MqQo2jNFdWea4kMeYpBulUHBSDX3PhGqv1AnTH9Y uIRw== X-Gm-Message-State: AOAM530bx/Zz5iVZy2PmT405wlWgjMyO3N54IJQflUfVlvXw9fuc/CVF 036F4N74CNULQ/fXe8LUc0E1SVfY8zw= X-Google-Smtp-Source: ABdhPJydmmJ67iS2UpM471FXwVloUuRuO9TKpEn1CkIFFloTzxbzv+vDN/dF/1gRQjzjlO92lxmVuw== X-Received: by 2002:a17:907:7f1b:b0:6df:7e0c:8842 with SMTP id qf27-20020a1709077f1b00b006df7e0c8842mr5726773ejc.225.1647544235722; Thu, 17 Mar 2022 12:10:35 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::758e]) by smtp.gmail.com with ESMTPSA id k19-20020a1709067ad300b006da92735c32sm2774894ejo.16.2022.03.17.12.10.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 12:10:35 -0700 (PDT) In-Reply-To: <86mtho5y56.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 17 Mar 2022 19:09:13 +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:228505 Archived-At: On Thu, 17 Mar 2022 at 19:09, Juri Linkov wrote: >> My idea is: >> >> - The users of the feature are Elisp programmers / package authors. >> - I don't think end users can meaningfully do anything directly with >> this new minibuffer hook. >> - If package X wants to take advantage of the feature, then it will >> either add minibuffer-lazy-highlight-setup to the >> minibuffer-setup-hook unconditionally, or it will define an >> X-lazy-highlight customization option to control this. >> >> So I think the conclusion is that the current approach in my patch is an >> good way to proceed here? > > So do you think end users should not be able to decide where they want > to use this feature? For example, if one user will want it for 'occur', > but another user doesn't want it in the 'occur' regexp-reading minibuffer, > they should have no choice? Of course there should an option, maybe occur-lazy-highlight. This is why isearch.el itself should _not_ contain a customization option called `minibuffer-lazy-highlight': each use (or group of uses) of this functionality should define their own customization option. >>>>> 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. >> >> I would suggest taking a look at isearch-mb. I think the code is pretty >> tight, and I would be unable to shorten the implementation other than by >> deleting comment :-) > > I already looked at isearch-mb. Adding the same to isearch.el > will take only 52 lines. Okay, I can give my opinion about these changes if you wish. >>>>>> 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. >> >> For one thing, isearch-mode has 2 essential commands (repeat forward and >> backwards), a couple more necessary ones (quit, abort, scroll, >> beginning/end of buffer, mode toggles), and then a number of commands >> that end the search with a special action (query-replace, etc.). >> >> These little details add up to the 283 lines in isearch-mb.el currently >> has. > > I wonder how this is affected by scroll, beginning/end of buffer, mode toggles? > These commands don't use the minibuffer. I probably misunderstood you then. I thought you wanted to allow C-s and C-r in isearch-edit-string to go back and forth in the search buffer, but apparently this is not the case. (Then I need to see your 52-line patch to understand what exactly you mean...) >>>>>> - 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? >> >> Okay, I'm not against this, but let's think about the names of these user >> options. The existing option is named query-replace-lazy-highlight, >> which seems to exactly describe the new feature. The existing feature >> would more specifically be called perform-replace-lazy highlight. > > Do you mean lazy-highlight in the minibuffer that reads a string to replace? > Then it could be named query-replace-read-lazy-highlight. I personally find it a bit unnecessary to have separate options for query-replace-read-lazy-highlight and query-replace-lazy-highlight. Of course it's nice to have fine-grained control, but at some point it just becomes too difficult to configure things. But I don't mind adding it.