unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: emacs-devel@gnu.org
Subject: Re: Is it valid to call isearch-filter-predicate outside isearch?
Date: Sun, 04 Jun 2023 02:06:46 +0200	[thread overview]
Message-ID: <87leh02iqx.fsf@web.de> (raw)
In-Reply-To: 87wn0lkkod.fsf@localhost

Ihor Radchenko <yantar92@posteo.net> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> >> 2. It feels against the interface. If advising this predicate is
> >>    expected, why not convert it into an abnormal hook?
> >
> > It's more flexible and expressive, as Drew already mentioned.  For
> > example, how the members of a hook are logically combined (`and'ed,
> > `or'ed) is fixed in a hook, but not when using advising.
>
> Interesting.
> From Elisp Tips in the manual, I always felt that using advices is
> always frowned upon. And you are suggesting that they are the better way
> to go in these situations.
> I am wondering if this thing with modifying predicates should be
> documented somewhere and recommended approach.

Not sure if we have a consensual approach at all.  But Note this is not
about modifying predicates, it's about modifying variables with function
bindings (in my eyes).  Yes, we don't want to use advices to change
named functions.

But when speaking about modifying function valued variables (or places)
advising has clear advantages: getting to the old value works more
transparently, and interfering actors have some more ways to control
their interaction.

I guess we will have to decide by case whether introducing a hook or
using advices on function valued variables or overwriting a binding with
plain `setq' makes more sense.

But maybe let's continue discussing this in the thread that Drew has
started.


> > I also wonder about the `kill-variable' calls: what if the user or a
> > third-party mode want to have own buffer-local settings for these?
> > We then erase
> > them when killing the local variables.  With using an advice on these
> > the worst thing that could happen is that we leave a buffer local
> > variable with the same binding as the global one, where we started with
> > no buffer local binding.
>
> May you please elaborate? I am not sure what `kill-variable' calls you
> are referring to here.

To those in `wdired-change-to-dired-mode:

#+begin_src emacs-lisp
  (when wdired-search-replace-filenames
    (remove-function (local 'isearch-search-fun-function)
                     #'dired-isearch-search-filenames)
    (kill-local-variable 'replace-search-function)
    (kill-local-variable 'replace-re-search-function)
    ;; Restore dired hook
    (add-hook 'isearch-mode-hook #'dired-isearch-filenames-setup nil t))
#+end_src

This demonstrates a problem when not using an advice: to get rid of the
temporary new binding you simply kill the local variable, but this can
be problematic, especially when we did not create it (but maybe someone
third).


Michael.




  reply	other threads:[~2023-06-04  0:06 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             ` [External] : " Drew Adams
2023-06-01  8:10               ` 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 [this message]
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=87leh02iqx.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --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).