[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Can a 'let' ever lack an 'unlet' in the context of variable watchers?
From: |
Arsen Arsenović |
Subject: |
Can a 'let' ever lack an 'unlet' in the context of variable watchers? |
Date: |
Tue, 30 Jan 2024 04:05:19 +0100 |
Hi,
I've been attempting for a while now to triage why
file-name-handler-alist gets reset to nil on my end sporadically (~once
a day, with potentially hours before I notice). To that end, I've
attempted to employ a variable watcher. This variable-watcher grew
increasingly complex as I tried to get as precise of a check as possible
(given that a lot of things change file-name-handler-alist all the time
it was way too over-verbose to try to just log or debug on everything).
Given that this appears to affect global state outside of a lexical
binding (since it persists for a very long time), I figured I should
ignore all changes to file-name-handler-alist that happened during a
'let'.
In an attempt to do this, I started tracking how deep in the 'let'-stack
a given variable change is using code similar to the following:
(setq arsen--test-depth 0)
(defun arsen--test (symbol newval operation where)
(setq arsen--test-depth
(+ arsen--test-depth
(pcase operation ('let 1) ('unlet -1) (_ 0)))))
(add-variable-watcher 'file-name-handler-alist
'arsen--test)
(extracted from my full and quite ugly variable watcher)
However, the current value, as I write this message, of
arsen--test-depth is 3.
This only happens when my 'full' variable watcher is in effect AFAICT,
so I suspect that somehow it prevents unlets from being counted (note
that the setq above is the first thing in the 'full' variable watcher
too, so I don't think it can be an error that prevents this code from
running, and debug-on-error caught nothing anyway), but I am unsure
about whether that is the case.
Are there any circumstances in which a 'let' won't have a matching
'unlet'? Is there a better way to achieve what I am looking for
(detecting variable changes that affect the global/dynamically bound(?)
value of file-name-handler-alist)?
Thank you in advance, have a lovely night :-)
PS: FWIW, but I am unsure about the viability of this, this bug really
seems to act like a let that never got 'undone', especially since I
don't see a reason for anything to be dynamically setting
file-name-handler-alist.
--
Arsen Arsenović
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Can a 'let' ever lack an 'unlet' in the context of variable watchers?,
Arsen Arsenović <=