From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: Is it valid to call isearch-filter-predicate outside isearch? Date: Sun, 04 Jun 2023 02:06:46 +0200 Message-ID: <87leh02iqx.fsf@web.de> References: <875y8nks9t.fsf@localhost> <87fs7c10cq.fsf@web.de> <87v8g79zoe.fsf@localhost> <87sfbasr8m.fsf@web.de> <87y1l244hz.fsf@localhost> <87o7lxpip9.fsf@web.de> <87wn0lkkod.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="452"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:hITWC86rUBkDuCbSZhG94js0Plo= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 04 02:07:59 2023 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 1q5bHr-000AR4-6k for ged-emacs-devel@m.gmane-mx.org; Sun, 04 Jun 2023 02:07:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5bGz-0005K7-LT; Sat, 03 Jun 2023 20:07:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5bGy-0005Jy-96 for emacs-devel@gnu.org; Sat, 03 Jun 2023 20:07:04 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5bGt-00015N-AU for emacs-devel@gnu.org; Sat, 03 Jun 2023 20:07:04 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1q5bGo-0009A4-Iu for emacs-devel@gnu.org; Sun, 04 Jun 2023 02:06:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306597 Archived-At: Ihor Radchenko writes: > Michael Heerdegen 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.