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.devel Subject: Re: [WIP PATCH] Controlling Isearch from the minibuffer Date: Thu, 13 May 2021 19:31:32 +0300 Organization: LINKOV.NET Message-ID: <87tun6n12v.fsf@mail.linkov.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10733"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 18:51:51 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 1lhEYx-0002ef-G3 for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 18:51:51 +0200 Original-Received: from localhost ([::1]:34906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhEYw-0006fa-4e for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 12:51:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhEFe-0006zx-BM for emacs-devel@gnu.org; Thu, 13 May 2021 12:31:59 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:50867) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhEFa-0004v6-4u for emacs-devel@gnu.org; Thu, 13 May 2021 12:31:54 -0400 X-Originating-IP: 91.129.102.166 Original-Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166]) (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id AE257FF80A; Thu, 13 May 2021 16:31:44 +0000 (UTC) In-Reply-To: <87bl9fr7xh.fsf@gmail.com> (Augusto Stoffel's message of "Wed, 12 May 2021 22:52:42 +0200") Received-SPF: pass client-ip=217.70.183.199; envelope-from=juri@linkov.net; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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:269249 Archived-At: > 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. > 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) > 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. > 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.