emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!


From: Alan Mackenzie
Subject: Re: Patch: Blunderbuss ".dir-locals.el" raises everything in its path!!
Date: Wed, 15 Jul 2009 19:00:05 +0000
User-agent: Mutt/1.5.9i

Hi, Jan, Yidong,

On Wed, Jul 15, 2009 at 09:55:43AM +0200, Jan Djärv wrote:

> Alan Mackenzie skrev:

> >Here's a preliminary patch which I think fixes the code, though I've
> >only tested it briefly.  It seems to work for the case you (Jan) were
> >hit by.

> >Now, any CC Mode style set by `c-file-style' will leave unchanged
> >those style variables (e.g. `c-cleanup-list') which have already been
> >given real values.

> >I expect and intend that if the `c-file-style' mechanism is used
> >twice, the second one (in the file's Local Variable section) will
> >prevail over the first one (in some .dir-locals.el), whilst
> >respecting the non-default value of `c-cleanup-list'.

> >Jan, please try it out!

> It works if I set c-cleanup-list with customize, but not if it is set in 
> the c-common-mode-hook (using add-to-list).

Yes.  Sorry.  I think we agree that a setting for c-cleanup-list made in
a hook function should take priority over any (semi-implicitly) requested
by c-file-style.  I think I can see how to do this, now.

I tried the following settings, at the same time:

(i) In .dir-locals.el:
     (c-mode . ((c-file-style . "Linux")
                (c-basic-offset . 7)))

(ii) In .../src/xftfont.c:
    /*
     * Local Variables:
     * c-file-style: "BSD"
     * c-basic-offset: 10
     * End:
     */

In xftfont.c, I got the style as "Linux" and c-basic-offset as 10, i.e.
a mixture of these two.  This happens because the CC Mode routine does 

    (assq 'c-file-style file-local-variables-alist)

, hence finding the earliest entry for c-file-style, whilst the other
variables are just bashed through, causing the latest entry to prevail
over earlier ones.

Yidong, hack-local-variables desperately needs refactoring.  It was sort
of tolerable when only file local variables were involved, but now it's
all but unreadable and ununderstandable (should this just be
derstandable?)

In particular, there's no great care taken about how the local variable
settings from the two sources get combined.  How about the following
idea: when a setting from the Local Variables: section is to be pushed
onto file-local-variables-alist, any exisiting element for the same
variable is first removed?

This way, a file's Local Variables section will prevail over
.dir-locals.el.

>       Jan D.

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]