From: "Davis Herring" <herring@lanl.gov>
To: "Tassilo Horn" <tassilo@member.fsf.org>
Cc: emacs-devel@gnu.org
Subject: Re: How to debug modification to a variable value?
Date: Tue, 26 Jan 2010 13:04:49 -0800 (PST) [thread overview]
Message-ID: <45732.130.55.118.19.1264539889.squirrel@webmail.lanl.gov> (raw)
In-Reply-To: <87636p5k9u.fsf@thinkpad.tsdh.de>
> "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.
next prev parent reply other threads:[~2010-01-26 21:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-25 20:52 How to debug modification to a variable value? Tassilo Horn
2010-01-25 21:08 ` Drew Adams
2010-01-26 8:00 ` Tassilo Horn
2010-01-26 15:17 ` Stefan Monnier
2010-01-26 16:49 ` Richard Stallman
2010-01-26 21:02 ` Stefan Monnier
2010-01-26 18:02 ` alin.s
2010-01-27 7:37 ` Andreas Roehler
2010-01-27 8:24 ` Tassilo Horn
2010-01-27 8:51 ` Andreas Roehler
2010-01-25 22:30 ` Davis Herring
2010-01-26 8:43 ` Tassilo Horn
2010-01-26 21:04 ` Davis Herring [this message]
2010-01-27 7:50 ` Tassilo Horn
2010-01-27 15:42 ` Davis Herring
2010-01-26 15:52 ` alin.s
2010-01-26 20:26 ` Tassilo Horn
2010-01-27 8:13 ` alin.s
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45732.130.55.118.19.1264539889.squirrel@webmail.lanl.gov \
--to=herring@lanl.gov \
--cc=emacs-devel@gnu.org \
--cc=tassilo@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.