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

[Ken Raeburn]

On Jul 13, 2009, at 04:19, Alan Mackenzie wrote:
> No.  They should act as a project wide default, which a user can
> occasionally vary as he sees fit.  The problem is not that .dir- 
> locals.el
> exists, but that it takes precedence over a user's c-mode-hook, or a
> top-level (setq c-cleanup-list) in .emacs.  Jan complained that he was
> left with no way to set c-cleanup-list.  (M-: (setq ....) doesn't  
> count
> as "a way" here.)

Isn't it just as much a problem if c-cleanup-list is set in file local  
variables?

> c-cleanup-list is partly project conventions (in that it can implement
> formatting rules), partly personal preference (in that it enables
> electric action in a C buffer).  For example, a project may specify  
> the
> 'brace-else-brace' convention (see page "Clean-ups" in the CC Mode
> manual), but a hacker may not want this to be done electrically in his
> Emacs.

Maybe the formatting rules and electric actions need to be better  
separated, so a project can control formatting and let the user  
dictate electric action (or, which actions should be done  
electrically, when they're enabled at all).  Maybe c-cleanup-list  
should never be set in either .dir-locals.el or in file local  
variables in a shared and published project.

On the other hand, the first message in this thread was more about c- 
file-style, which seems to me to be entirely appropriate for  
either .dir-locals.el or file local variables, in shared code where  
different people may have different personal styles that should not be  
imposed on the project.  It can't force them to obey the project style  
guidelines, but it can make it more easy and natural to do so.

I haven't experimented much with .dir-locals.el, but browsing the  
documentation and code suggests that the application and "safeness"  
tests apply to the combination of file local variables and .dir- 
locals.el settings, so I don't see much difference conceptually as to  
whether certain variables should or should not be set in one but not  
the other.

Ken