From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: Alan Mackenzie <bug-cc-mode@gnu.org>,
Martin Stjernholm <mast@lysator.liu.se>,
emacs-devel@gnu.org
Subject: Re: Ordering in `source' property, and auto-loading of c-lang-defconsts
Date: Sun, 31 Aug 2014 20:52:40 -0400 [thread overview]
Message-ID: <jwvy4u4rx9n.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20140831212355.GA4401@acm.acm> (Alan Mackenzie's message of "Sun, 31 Aug 2014 21:23:55 +0000")
Thanks, Alan.
> The symbol-value is an alist of elements which look like, e.g., (c-mode .
> "[[:alpha:]_]"), there being a separate element for each language. It is
> generated by byte-compiling cc-mode.el, and contains the final value of
> the c-lang-defconsts, used in generating the c-lang-defvars (which are
> ordinary variables in the standard obarray).
Right, in the mean time I figured this part, indeed. t doesn't hold
"the final alist" but rather "an alist of final values" (i.e. only
contains the final value for those major modes for which it's been
computed).
Basically, we evaluate those values lazily and memoize the result in
these alists.
>> - Do those symbols hold other information (I don't see another property
>> being used, nor does the symbol-function slot seem to be used, but
>> maybe I just missed it)?
> The symbol-function is not used (there is no occurrence of
> "symbol-function" in cc-defs.el). Some other properties stored in the
> obarray are `variable-documentation' and `dependents', the latter being a
> list of `c-lang-defconst's which use the current `c-lang-defconst' (the
> list can contain the current `c-lang-defconst' "recursively"). I don't
> think there are any more.
Ah, yes, I see it now, thanks. It seems the `variable-documentation'
property is only used to transfer the docstring from the c-lang-defconst
to a corresponding c-lang-defvar. And the `dependents' seems to be only
used to track which vars need to be recomputed (which part of the
memoization table needs to be flushed) when a c-lang-defconst is
re-evaluated (I guess typically be M-C-x or by re-loading cc-langs, so
it's really only used for development purposes).
>> Here's the main question:
>> - Why is this FILE needed? Why is it important to preserve ordering
>> between various FILEs? Why do we sometimes `load' those FILEs (in
>> c-find-assignment-for-mode)? Which kind of concrete situation is this
>> supposed to address?
> I'm not unconfused enough to say. Sorry. But it seems it will have to
> do with modes derived from CC Mode using c-add-language. I'm trying to
> work out why we need to load the source files when all the information is
> already contained in the c-lang-constants obarray.
I can't figure out when we'd (auto)load a file based on this FILE info.
OTOH I did figure out why we otherwise need this FILE info: if
a "c-lang-const" is defined by various c-lang-defconst (as is the
case if you have an unbundled amjor mode that uses the CC-mode engine),
this lets you correctly handle the reloading of a file that calls
c-lang-defconst, only replacing the part of the definition that this
file had provided. So again (like `dependents') this seems to be mostly
useful for development purposes.
>> My vague understanding is that we want to allow c-lang-defconst to be
>> called (for the same variable) from different files for different
>> major modes. Of course, for those modes supported natively by CC-mode,
>> they're all in cc-langs.el .....
> There are some c-lang-defconsts in cc-fonts.el.
Thanks for the heads up, I hadn't noticed them. I'll take a look (tho
expect it won't make much difference in the sense that these vars are
still defined in only one file for the bundled code. I.e. the `source'
property is still a single-entry list).
Looking at `source-pos', I think I see one reason why ordering matters:
in order for the definition of a variable to be able to refer to the
definition of that same variable but in its parent major-mode, it is
necessary for the two definitions to appear in the right order. This is
not inherent, but is an artifact of the way the lookup is done to try
and make it work without bumping into an infinite cycle.
If my analysis is right, then I think I see a way to make it a bit more
robust and cleaner, getting rid of those ordering constraints.
Stefan
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
next prev parent reply other threads:[~2014-09-01 0:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 14:09 Ordering in `source' property, and auto-loading of c-lang-defconsts Stefan Monnier
2014-08-31 21:23 ` Alan Mackenzie
2014-09-01 0:52 ` Stefan Monnier [this message]
2014-09-01 22:43 ` Avoiding loading cc-langs (was: Ordering in `source' property, and auto-loading of c-lang-defconsts) Stefan Monnier
2014-09-04 2:38 ` Avoiding loading cc-langs Stefan Monnier
2014-09-06 11:10 ` Alan Mackenzie
2014-09-06 10:12 ` Avoiding loading cc-langs (was: Ordering in `source' property, and auto-loading of c-lang-defconsts) Alan Mackenzie
2014-09-08 1:51 ` Avoiding loading cc-langs Stefan Monnier
2014-09-08 15:46 ` Glenn Morris
2014-09-08 18:45 ` Stefan Monnier
2014-09-08 18:52 ` Glenn Morris
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=jwvy4u4rx9n.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=bug-cc-mode@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mast@lysator.liu.se \
/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.