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.devel Subject: Re: [ELPA?] Controlling Isearch from the minibuffer Date: Thu, 13 May 2021 22:12:25 +0200 Message-ID: <87lf8i8kba.fsf_-_@gmail.com> References: <87zgx5cz33.fsf@gmail.com> <87o8djohqf.fsf@mail.linkov.net> <87eeeenxqq.fsf@gmail.com> <87h7jath3m.fsf@mail.linkov.net> <87mtt0wj37.fsf@gmail.com> <87cztvx4dc.fsf@mail.linkov.net> <87bl9fr7xh.fsf@gmail.com> <87tun6n12v.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="22586"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 22:13:42 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lhHiH-0005lh-Df for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 22:13:41 +0200 Original-Received: from localhost ([::1]:44684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhHiG-0007EO-GL for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 16:13:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhHh8-0006TY-S9 for emacs-devel@gnu.org; Thu, 13 May 2021 16:12:30 -0400 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:37875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhHh6-0004Hb-LF for emacs-devel@gnu.org; Thu, 13 May 2021 16:12:30 -0400 Original-Received: by mail-ej1-x632.google.com with SMTP id w3so41597183ejc.4 for ; Thu, 13 May 2021 13:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=aUvMkvaS4ReOpP3WzRNJUuiKdh4aqXkvnbSgrCS4u1I=; b=QgX3bedYBLQ0Lr4jurxoQ51t+djI0GZapKFWE0ON6do1u8oUVnC9LKQTrFoGP3HAQP swnmBdw9dizWXKcJ2Yv5VktPn17f2u+zIheF38LxItlATP/fI3S4R29vneJ4ugXqTqtR w2pcWAyJWg15AVOFw40bts/GQgejAaMTic3WL/mh3vwXgc7OUHMuUKCIGDIc6X7fmnoD iLY9KxsDg7n0lCdFjKPGURgS94cm8YAXx5lsspnO81PUbMBZRQkMzWt9bJAkywdcCJF0 BNrc1BKaysN9Bbql6HhZcPTtbOkAebubIyTpzTpPCNvsfi/2DU5IlHLGGfIb6Su1Sncj ZlJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=aUvMkvaS4ReOpP3WzRNJUuiKdh4aqXkvnbSgrCS4u1I=; b=uT2uYIHTuIVIvQpHqlWOUhld3u68fW8fkFiqu849TCT/6F3oZddZOIIW41pYAAO3GN /7rKN8SFekg4sdTJQu6JtXG5ZLNZH+ePfrxL/sbKX/qYRZMPTSaf7oCqOos1iAMGDYeD knoTnUuQl8FGadSzNukcmLr7f3Bf+prU4LiipeE2BVNYnqqQV6QgvAER48NUGmMh+B7S 9zlYjbzWzeEkTuM+KzmgFfhSspBx0pB6erXCD7BYfwvszLiFcpsSAm3a1kZQFkenoXJN lFHcoCfGqCRUmiackndqoXD/PLuEejyRHAUrb/FpDJIng5KRuHAIuwLVTnSFkWf2+bJv fCvw== X-Gm-Message-State: AOAM532a6ur0h4STxrgCJYiGHz3k+UI+GLarpNbJFuEcHgn04oEv8YI6 TYGHyAclVSx5pjYbOrTWx3vKMv9fYGE= X-Google-Smtp-Source: ABdhPJxj/VsbS/xhOSIcKkDvMjMEpJP9pl0YuQG+4HMx4ewaCnZjl4cYE9k9gNtUZrnoN5BR1WEtiw== X-Received: by 2002:a17:907:7848:: with SMTP id lb8mr22960603ejc.494.1620936746442; Thu, 13 May 2021 13:12:26 -0700 (PDT) Original-Received: from ars3 ([2a02:908:2211:8540::68a]) by smtp.gmail.com with ESMTPSA id gt12sm2324391ejb.60.2021.05.13.13.12.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 May 2021 13:12:25 -0700 (PDT) In-Reply-To: <87tun6n12v.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 13 May 2021 19:31:32 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=arstoffel@gmail.com; helo=mail-ej1-x632.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269256 Archived-At: On Thu, 13 May 2021 at 19:31, Juri Linkov wrote: Hi Juri, I'm pretty convinced that the approach of my first patch (`with-isearch-window' macro, etc.) is the right way to implement this and possibly other future features. On the other hand, I understand that it would be premature to just change isearch.el in this direction without a deeper reflection and further testing. So it seems that providing the feature in a package would be the best way to proceed here. Then we can observe which hurdles arise and make a more informed change to isearch.el in the future. I just worry a bit this may end up being a very distant future :-). What to you think? I would then maintain the package on Github. How does the submission process to ELPA work? Once again, here's the link: https://github.com/astoff/isearch-mb >> I mean keyboard quit. You can see the error message by evaluating this >> and then pressing C-g: >> >> (add-hook 'post-command-hook >> (lambda () (read-from-minibuffer "test")) t t) > > It's possible to handle C-g when needed: > > (add-hook 'post-command-hook > (lambda () (condition-case nil > (read-from-minibuffer "test") > (quit))) > t t) > >> Using a timer with zero delay instead works better. > > Using a timer is still a hack. What could avoid a hack is > using the existing solution like recursive-edit is called > at the end of isearch-mode. > >> Setting `isearch-message-function' is of no help, because there are some >> tests for `(null isearch-message-function)' as well as some explicit >> calls to `(isearch-message)' in isearch.el. As far as I can see, there >> is no alternative to modifying the function `isearch-message' itself. > > Tests for `(null isearch-message-function)' were added as a temporary > workaround until lazy count will be implemented in the minibuffer. > We need to remove these workarounds anyway. So using isearch-message-function > should be the right thing to do. Okay, that' a low hanging fruit then. > >> Moreover, one still has to manually keep a list of commands that need to >> switch to the search buffer (cf. `isearch-edit--buffer-commands') and >> commands that end the search (cf. `isearch-edit--quitting-commands'); I >> see no way around that. Therefore, I see no advantage here over the >> proposed `with-isearch-window' macro. > > There is no need to keep commands in a list. The isearch-allow-scroll > feature uses symbol properties like > > (put 'recenter 'isearch-scroll t) > (put 'recenter-top-bottom 'isearch-scroll t) > (put 'reposition-window 'isearch-scroll t) > Fine, but this still means manually curating the list of relevant commands. I guess there's no way out of it. >> I admit that the `with-isearch-window-quitting-edit' macro of my old >> patch seems pretty ad-hoc. However, it could be replaced by a >> `with-isearch-done' macro which is of more general nature. If you >> search isearch.el for calls to `isearch-done', you'll see that some are >> of the form >> >> (let (;; Set `isearch-recursive-edit' to nil to prevent calling >> ;; `exit-recursive-edit' in `isearch-done' that terminates >> ;; the execution of this command when it is non-nil. >> ;; We call `exit-recursive-edit' explicitly at the end below. >> (isearch-recursive-edit nil)) >> (isearch-done nil t) >> >> while a few others seem to just don't take into account that we may be >> ending a recursive edit. > > Indeed, this is an old unsolved problem, and setting isearch-recursive-edit > to prevent calling exit-recursive-edit is a workaround. We need to fix this > anyway. Then calling isearch-edit-string with read-from-minibuffer > at the end of isearch-mode should not be different from the current > calling of recursive-edit at the end of isearch-mode. > Both problems will use the same solution. > >> So an `with-isearch-done' macro (which ends isearch, executes the body, >> then possibly ends a recursive edit, and at the same time takes care to >> unwind the minibuffer if we happen to be in `isearch-edit-string') would >> seem a reasonable addition to isearch.el. > > Do you mean to pack the current isearch-recursive-edit/exit-recursive-edit > as a macro and use it in commands like isearch-query-replace, and also to > call exit-minibuffer to handle minibuffer exiting too. This could be fine > if no better solution is found. > Yes. Like I said, maybe this needs more time to mature, and seeing how well the advice-based implementation of the isearch-mb package works may inform this question. >> Sorry for the long message :-) > > It would be more appropriate to be sorry for the long patch ;-) > Usually a long patch means there are still unsolved workarounds > for old problems such as with isearch-message-function and > exit-recursive-edit above, etc. After solving these problems > the patch should become much shorter. Okay, I'll try to be more granular next time. I still want to work on the lazy highlight for `isearch-edit-string' and `query-replace' and friends, for instance.