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

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > sjt wrote:

 > > The issue Alan is raising is precisely that *somebody else* is
 > > overriding the user's settings.
 > 
 > Thank you!  That is EXACTLY what I'm raising.  What's more, the
 > overriding is surreptitious - it took Jan some time to find out what was
 > going wrong.  How do you turn off this .dir-locals.el thingy?

I thought .dir-locals.el was an abbreviated way of setting the same
file-locals in every file, and turned off the same way, with
`enable-local-variables'.

But really, you don't want to turn that off.  You want to fix the
.dir-locals.el file.

 > > I agree with Miles:
 > 
 > >  > It also seems downright bizarre to tell people not to set
 > >  > c-file-style in .dir-settings.el -- my sense is that most developers
 > >  > would agree that if a project has C style conventions, they should
 > >  > override the user's personal preferences...
 > 
 > 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.

That's no bug, that's a feature.  I'm sorry, Alan, but it's totally
unrealistic to hope that average users will take special care to write
hook functions or customizations that worry about projects (that "they
don't even know what they is", to borrow an old Bill Cosby line) that
have special needs.  Most users don't bother to read style guides, and
even fewer would be willing to write conditionals in their hooks.
There needs to be a way to override user globals, per-project, or
per-file.

Now, if `enable-local-variables' doesn't control .dir-locals.el, for
those cases where the user really wants to re-override, that's a bug
IMHO.  If there's no way to control it, then both the author and
committer involved should be sentenced to use Emacs with their keymaps
rot13'd until they get used to it, then rot13'd back. :-)

 > Jan complained that he was left with no way to set c-cleanup-list.
 > (M-: (setq ....) doesn't count as "a way" here.)

Of course it does.  If something that users would often reasonably
want to change, then projects have no business setting it.  The bug is
in the usage by whoever put a setting for c-cleanup-list in a file
local context, not in the precedence.

Ie, the problem is that `c-cleanup-list' controls a bunch of electric
behaviors, and those should never be enabled or disabled in a file
local variable (including dir-locals).  `c-cleanup-list' should be
strictly for the user.

Of course it should be possible for a project to specify a preferred
style to "clean up to", and to enable a "write-region-pre-hook" which
style-checks the buffer, and if it fails, does a "your buffer's style
stinks!  Save anyway? [yes/no] " prompt.  But the project must not try
to enforce a particular way to achieve that style.

 > > Indeed.  I think that needs to be sorted out here is Alan's intuition
 > > that C style conventions are a matter of personal preference.
 > 
 > Hey, that's not fair!

:-)  Did I get your attention?

 > 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).

It certainly is fair.  If you confound project conventions with
personal preferences, either conceptually or in the design of your
software, that's not just your problem, it becomes the users' and
projects' problem.  Project conventions must be separated from
personal preferences or you end up with the kind of precedence
deadlock, user vs. project, that we see here.