GNU bug report logs - #72229
(setq overriding-terminal-local-map nil) in isearch-done

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 72229 <at> debbugs.gnu.org
Subject: bug#72229: (setq overriding-terminal-local-map nil) in isearch-done
Date: Tue, 23 Jul 2024 20:46:33 +0300

>> This mechanism looks like a variable watcher enabled by
>> `add-variable-watcher'.
>> So you could add a watcher that conditionally controls variable
>> modifications.
>
> I don't think variable watchers are very helpful here.  They don't solve
> the underlying problem: potentially infinite variables of the same name
> can exist, shadowing each other, with values partly sharing structures.
>
> Using variable watchers I can see whether a variable value gets shadowed
> or unassigned using a set operation - but I can't know whether the
> previous value still exists, as binding of some other variable, and if
> it will be stored back into the variable.  Nor do I have access to old
> bindings and their values until the program assigns it back to the
> variable.
>
> I saw that in Bug#70938.  Manipulations of a variable can interfere in
> annoying ways.
>
> Functions are different.  You have only one dynamic binding (unless in
> the rare case of using `cl-letf', which is extremely rare).  And you
> always have access to it to undo any prior modification.

I remember Stefan M suggested to use function variables as much as possible
such as (defvar isearch-filter-predicate #'isearch-filter-visible), then
it's easy to add more filters with add-function.

But I'm not sure is it possible to do the same with a variable
getter function?  I mean that instead of (funcall isearch-filter-predicate)
such a getter function could be called (get-value isearch-filter-predicate)
to access the variable value.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.