unofficial mirror of
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]


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

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

(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
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

                 reply	other threads:[~2024-01-30  3:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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.
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).