Re: How to debug modification to a variable value?

[Davis Herring]

> "Gone" means, it has the buffer-local value nil.  So there seems to be
> no call to `kill-local-variable'.

That narrows the possibilities, although `make-local-variable' could have
happened later.

> There's no `kill-[all-]local-variable[s]', and the `setq' of that
> variable is isolated in one command (see end of this message), which is
> never called internally, only by a keybinding.

Don't forget `set'.  It's unlikely but not impossible some generic code is
doing something like (set (caar (buffer-local-variables)) nil).  So of
course check with "emacs -Q", and enable as little as possible that might
be trying to be clever like that.

> Sounds good, but how do I do that?  Especially the "find where the
> buffer-local value of the variable is stored" part...

(I think this has been adequately addressed by others.)

>> Meanwhile, my psychic powers suggest that you have a `let' binding of
>> the variable in question and switch buffers within the `let', or else
>> that something is reasserting your major mode so that
>> `kill-all-local-variables' is getting called.
>
> Hm, the problem occured while I was using many different frames, which I
> didn't use till now, so something in this direction seems possible.  But
> between the variable is set buffer-locally to some alist and the
> variable is set buffer-locally to nil, there was only one C-x C-s
> without switching frames/buffers at all.

And you're sure that there are no relevant `let's?  There's actually a bug
there, which I failed to actually mention: see
http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=3467

>> You could test for the latter with the `permanent-local' property.
>
> Oh, I didn't know that property.
> [...]
> I don't know if this is appropriate for `tg-schema-alist'.  It
> determines the completion possibilities and highlighting, and is not
> strictly related to the current buffer/file, but to another file a user
> can select and switch.

I didn't mean that your variables should really use it.  Just that you
could put it on them for debugging to see whether they were getting killed
by `kill-all-local-variables', since it will spare permanent locals.  Of
course, you say it still has a local value, so that's probably not
happening, but you could check anyway, for the odd case of
`kill-all-local-variables' + `make-local-variable' (not
`make-variable-buffer-local') that looks very much like `setq' with nil.

> So tg-mode contains
> [...]
> and in greql-mode (which requires tg-mode), there is the only function
> modifying the value of `tg-schema-alist' by assigning the buffer-local
> value of a temporary buffer to the buffer-local value in the query
> buffer.

Aha!  Now we can ignore most of what I've written so far (except perhaps
for reference for future bugs).

`tg-init-schema' also sets `tg-schema-alist', of course; that's how
`greql-set-graph' gets it.  And I see that `tg-eldoc-init' adds that
function to `after-save-hook' (globally!), and that `tg-initialize' adds
-that- to `eldoc-mode-hook' (globally!), and that `tg-mode' calls -that-.

While greql-mode.el never actually invokes `tg-mode' for you, I suspect
that at some point your Emacs did run `tg-mode', which called
`tg-initialize', which registered `tg-eldoc-init', which got called
(perhaps in some other buffer) by `eldoc-mode' and registered
`tg-init-schema', which got called by `basic-save-buffer' in your GReQL
buffer.  This non-local, delayed effect probably does look a lot like
magic and probably does only happen in some Emacs sessions.

Am I right?

Davis

PS - (lambda (elem) (car elem)) is usually just written 'car or #'car.

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.