Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Trying to be more constructive: what about the appended patch? It should
> fix the problem reported here, and it is simple.

Yes, this fix is simple and is OK by me (I did mention it in an earlier
post in this thread IIRC).  It certainly will fix the issue.

To debug the underlying issue, do you have any tips on how I could catch
file-name-handler-alist becoming nil?  The obvious (variable watchers)
does not work due to frequency of change (and how many times it is
actually totally legitimate for that variable to become nil in a
let-binding), I fear, and I suspect I'll need to hack core sooner or
later.  Again, it feels almost like 'let' is broken, because this
happens outside of a let-binding context.

It would be nice to be able to record a backtrace of only variable
changes that are _not_ under a let (because, AFAIK, always, after a let
is done evaluating, the binding of a variable is restored to its
original value).  Since it seems that this variable becomes nil outside
of any lets, it'd be nice to isolate that case.

I've tried to count how "deep" I am in let-bindings using the let and
unlet events:

  (defun arsen--watch-file-name-handler-alist (symbol newval operation where)
    (setq arsen--watch-file-name-handler-alist-depthw
          (+ arsen--watch-file-name-handler-alist-depth
             (pcase operation ('let 1) ('unlet -1) (otherwise 0))))
             ...
  
  (add-variable-watcher 'file-name-handler-alist
                        'arsen--watch-file-name-handler-alist)

... but this proved futile (and would somehow end up not being zero
when I check after a while of running Emacs by typing
M-: arsen--watch-file-name-handler-alist-depth RET, despite not having
any lets in (debug) and (backtrace)).

Thanks in advance, have a lovely day.
-- 
Arsen Arsenović