unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Ihor Radchenko <yantar92@posteo.net>, Eli Zaretskii <eliz@gnu.org>
Cc: "juri@linkov.net" <juri@linkov.net>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Is it valid to call isearch-filter-predicate outside isearch?
Date: Wed, 31 May 2023 15:22:20 +0000	[thread overview]
Message-ID: <SJ0PR10MB548859F30DC333A9EE08B942F3489@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87o7m0k1li.fsf@localhost>

> >> I expected `isearch-filter-predicate' to be only used by isearch in
> >> isearch-mode. And thus I expected `isearch-mode-end-hook' to be called
> >> later.
> >>
> >> Isn't it a natural expectation?
> >
> > Evidently, that ship sailed a long time ago: "grep isearch-" yields
> > more than 60 hits in replace.el.  And then there are many hits in
> > comint.el, dired-aux.el, info.el, and even in simple.el.
> 
> Sure. I have no issue with this. That's why I asked to add a word of
> warning about the state of affairs to the docstring. It is not normal
> that major mode-specific predicates are used elsewhere.

Where do you find that "not normal" guideline? 

In any case, `isearch-filter-predicate' is not a
"major mode-specific" predicate.  `isearch-mode'
is a minor mode.

And note that the first line of its doc string
says that it's for "Isearch and replace commands."
                            ^^^^^^^^^^^
___

Wrt whether `isearch-done' should restore the
original/previous value of `isearch-filter-predicate':

Yes, there's a certain logic to expecting that
`isearch-done' would do that.

In my library `isearch+.el' `isearch-done' does it.

More precisely, it does it depending on a user
option, because the library has a feature that
lets you alter the predicate on the fly, and you
sometimes want to keep the modified predicate for
subsequent searching.  (You can toggle the option
value during Isearch using `C-z S'.)

The feature: You can add and remove any number
of search filters (predicates) while searching
incrementally.

The value of `isearch-filter-predicate' is
advised by predicates that you add, creating a
suite of predicates that act together.

(AFAIK, this is the only example of dynamically,
interactively, incrementally advising a function,
in this case the function value of a variable.)

See https://www.emacswiki.org/emacs/DynamicIsearchFiltering.

This is the user option that `isearch-done' uses:

 `isearchp-auto-keep-filter-predicate-flag' is a variable
 defined in `isearch+.el'.

 Its value is nil

 Documentation:

 Non-nil means automatically apply `C-z s'.
 Changes to `isearch-filter-predicate' are automatically kept for
 subsequent searches in this Emacs session when you exit Isearch'.
 You can toggle this option using `C-z S during Isearch.

And this is the advice that implements whether to
restore the value:

(defadvice isearch-done (after isearchp-restore/update-filter-pred
                         activate)
  "Reset `isearch-filter-predicate' or `isearchp-kept-filter-predicate'.
If `isearchp-auto-keep-filter-predicate-flag' is non-nil then set
`isearchp-kept-filter-predicate' to the current value of
`isearch-filter-predicate'.  Otherwise, do the opposite."
  (if isearchp-auto-keep-filter-predicate-flag
      (setq isearchp-kept-filter-predicate  isearch-filter-predicate)
    (setq isearch-filter-predicate  isearchp-kept-filter-predicate)))

So yes, in general it makes sense for `isearch-done'
to restore the predicate value.  But it can sometimes
make sense for it not to do so.  Whether it does so
or not should be under user and programmatic control.




  reply	other threads:[~2023-05-31 15:22 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-20 14:10 Is it valid to call isearch-filter-predicate outside isearch? Ihor Radchenko
2023-05-22 18:12 ` Juri Linkov
2023-05-31 10:08   ` Ihor Radchenko
2023-05-31 12:44     ` Eli Zaretskii
2023-05-31 12:56       ` Ihor Radchenko
2023-05-31 14:21         ` Eli Zaretskii
2023-05-31 14:38           ` Ihor Radchenko
2023-05-31 15:22             ` Drew Adams [this message]
2023-06-01  8:10               ` [External] : " Ihor Radchenko
2023-05-31 23:10             ` Michael Heerdegen
2023-06-01 11:48               ` Ihor Radchenko
2023-06-01 23:30                 ` Michael Heerdegen
2023-06-02  8:58                   ` Ihor Radchenko
2023-06-01  6:38     ` Juri Linkov
2023-06-01 11:44       ` Ihor Radchenko
2023-05-31 23:17 ` Michael Heerdegen
2023-06-01  5:55   ` Eli Zaretskii
2023-06-01 23:13     ` Michael Heerdegen
2023-06-01  0:40 ` Michael Heerdegen
2023-06-01 11:42   ` Ihor Radchenko
2023-06-01 16:21     ` Juri Linkov
2023-06-02  8:56       ` Ihor Radchenko
2023-06-01 23:22     ` Michael Heerdegen
2023-06-02  9:07       ` Ihor Radchenko
2023-06-02 13:36         ` [External] : " Drew Adams
2023-06-02 23:06         ` Michael Heerdegen
2023-06-03  8:35           ` Ihor Radchenko
2023-06-04  0:06             ` Michael Heerdegen
2023-06-17 13:05               ` Ihor Radchenko
2023-06-18  2:48                 ` Michael Heerdegen
2023-06-18 11:31                   ` Ihor Radchenko
2023-06-04  2:06             ` Michael Heerdegen
2023-06-18 10:31           ` Ihor Radchenko
2023-06-18 21:39             ` Michael Heerdegen
2023-06-19 10:44               ` Ihor Radchenko

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=SJ0PR10MB548859F30DC333A9EE08B942F3489@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=yantar92@posteo.net \
    /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).