From: Juri Linkov <juri@linkov.net>
To: Augusto Stoffel <arstoffel@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: [WIP PATCH] Controlling Isearch from the minibuffer
Date: Thu, 13 May 2021 19:31:32 +0300 [thread overview]
Message-ID: <87tun6n12v.fsf@mail.linkov.net> (raw)
In-Reply-To: <87bl9fr7xh.fsf@gmail.com> (Augusto Stoffel's message of "Wed, 12 May 2021 22:52:42 +0200")
> 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.
next prev parent reply other threads:[~2021-05-13 16:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-08 10:13 [WIP PATCH] Controlling Isearch from the minibuffer Augusto Stoffel
2021-05-09 13:36 ` Alan Mackenzie
2021-05-09 17:58 ` Augusto Stoffel
2021-05-10 19:51 ` Alan Mackenzie
2021-05-11 9:00 ` Augusto Stoffel
2021-05-11 15:34 ` [External] : " Drew Adams
2021-05-11 18:31 ` Juri Linkov
2021-05-11 19:38 ` Drew Adams
2021-05-12 6:45 ` Augusto Stoffel
2021-05-12 12:44 ` Stefan Monnier
2021-05-12 15:31 ` Drew Adams
2021-05-12 22:17 ` Kévin Le Gouguec
2021-05-12 23:07 ` Drew Adams
2021-05-13 15:12 ` Kévin Le Gouguec
2021-05-12 21:09 ` Augusto Stoffel
2021-05-12 15:30 ` Drew Adams
2021-05-09 19:09 ` Juri Linkov
2021-05-09 19:05 ` Juri Linkov
2021-05-10 20:24 ` Augusto Stoffel
2021-05-10 21:17 ` Juri Linkov
2021-05-12 6:40 ` Augusto Stoffel
2021-05-12 17:13 ` Juri Linkov
2021-05-12 20:52 ` Augusto Stoffel
2021-05-13 16:31 ` Juri Linkov [this message]
2021-05-13 20:12 ` [ELPA?] " Augusto Stoffel
2021-05-14 1:17 ` Jean Louis
2021-05-14 8:36 ` Augusto Stoffel
2021-05-14 17:30 ` Augusto Stoffel
2021-05-14 18:20 ` Juri Linkov
2021-05-16 11:00 ` Augusto Stoffel
2021-05-16 18:19 ` Juri Linkov
2021-05-25 20:50 ` Juri Linkov
2021-05-29 11:48 ` Augusto Stoffel
2021-05-14 18:18 ` Juri Linkov
2021-05-16 18:12 ` Juri Linkov
2021-05-16 18:49 ` Augusto Stoffel
2021-05-21 9:09 ` Augusto Stoffel
2021-05-21 10:25 ` Eli Zaretskii
2021-05-21 11:56 ` Augusto Stoffel
2021-05-21 12:31 ` Eli Zaretskii
2021-05-21 12:49 ` Augusto Stoffel
2021-05-21 15:05 ` Stefan Monnier
2021-05-21 15:09 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tun6n12v.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=arstoffel@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).