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

[Alan Mackenzie]

Hi, Davis!

On Tue, Jul 14, 2009 at 07:05:20AM -0700, Davis Herring wrote:
> >> I don't think it's a feature that dir-locals.el takes precedence
> >> over mode-hooks (it's more of an accident that we consider
> >> sufficiently harmless not to fix it, especially since a fix would
> >> probably be difficult/inconvenient/buggy), but in this case it seems
> >> to provide just the behavior we want.  I mean we do want to "impose"
> >> the GNU style in our files, no matter what the user usually prefers.

> >> What am I missing?

> > That setting space-before-funcall in c-cleanup-list is a very
> > reasonable thing to do in the context of the GNU-style (why isn't it
> > on by default for GNU?), and in no way breaks the imposed style.  But
> > the old ways of doing that in the Emacs source tree doesn't work
> > anymore, and there is nothing in NEWS, and AFAIK, no discussion about
> > it has taken place.  It is just one of those frustrating
> > WTF-discoveries.

> That's the specific case that started this, yes.  But I think the general
> point (that Stephen has made) bears another statement: the variable
> `c-file-style' controls both things that ought to be the decision of a
> project (like indentation and brace placement) and things that ought to be
> the decision of each individual user (like what sort of cleanup to do
> automatically).  Once we realize that, the problem is obvious: that
> coupling of choices (that are properly made by different people) prevents
> _any_ order of precedence from being correct.

I don't quite agree.  The distinction between project things (e.g. brace
placement) and personal things isn't all that clear cut.  For example,
within c-cleanup-list, the effect of 'brace-else-brace (when "}\n  else
\n  {" has the \ns removed) might well be a project formatting standard,
yet 'space-before-funcall (inserts space into "foo()") might be personal.

How often do coding standards with such stupid finnicky formatting things
get observed at all?  ;-)

> There is the separate issue that .dir-locals.el is harder to notice than
> true file-local variables, and so confusion is likely when it does
> unexpected things (like this).  The proposed addition to the output of C-h
> v would go a long way towards fixing that;

How about (message "~/emacs/.dir-locals.el" loaded for %s"
                   (buffer-file-name))
?  There's a very good chance a hacker would notice this.

> my implementation suggestion is to have `hack-local-variables' make
> (buffer-local) lists `file-locals' and `dir-locals' of symbols that
> have been made local for the appropriate reason.  (Of course, a later
> `setq' or `kill-local-variable' can render these lists inaccurate.  The
> latter doesn't matter, since C-h v would see that it wasn't local
> anyway.  The lists could contain their original local values as well to
> detect the former case.)

How about a flag for {en,dis}abling .dir-locals, independent from
anything to do with file local variables?

> Davis

-- 
Alan Mackenzie (Nuremberg, Germany).