[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-repl
From: |
Juri Linkov |
Subject: |
bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc. |
Date: |
Tue, 05 Apr 2022 20:12:16 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) |
> But that's a good point, we don't need a macro. Among several
> variations, we could make the setup code look like this:
>
> (minibuffer-with-setup-hook
> (minibuffer-lazy-highlight-init :case-fold case-fold-search
> :regexp regexp-flag
> ...)
> (query-replace-read-from prompt regexp-flag))
>
> where now `minibuffer-lazy-highlight-init' is not the function that
> initializes stuff, but rather a function that returns a closure that
> initializes stuff.
Looks good.
>> Please also note that condition-case can be replaced by
>> a hook in minibuffer-exit-hook that can remove highlighting
>> after exiting the minibuffer.
>
> If it was a `unwind-protect', I would agree. But I don't know how to
> simulate a `condition-case'. Specifically, how can we determine if some
> hook (the minibuffer-exit-hook in this case) is being run "normally" or
> as part of the recovery from a signaled error?
Shouldn't both cases clean up highlight from the buffer?
Then I see no need to distinguish each case. Or if really needed,
you can try to bind the cleanup to command-error-function.
>> Alternatively, the same lambda above could be added to
>>
>> (add-hook 'minibuffer-setup-hook (lambda () ...))
>
> Why was it again that we want to avoid saying something like this?
>
> (let ((case-fold-search whatever)
> (isearch-regexp regexp-flag))
> (minibuffer-with-setup-hook #'minibuffer-lazy-highlight-init
> (query-replace-read-from prompt regexp-flag)))
4 lines look nice, unlike 20 lines in one of your patches ;-)
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/01
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/01
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/01
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/02
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/03
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/03
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/04
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/05
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc.,
Juri Linkov <=
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/07
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/08
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/08
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Augusto Stoffel, 2022/04/09
- bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc., Juri Linkov, 2022/04/10