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

["Davis Herring" <herring@lanl.gov>]

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

My understanding is that people don't want _automatic_ cleanup forced on
them (so that they can edit as they're used to without having it change
things unexpectedly) even though they will follow the convention
eventually.  For indentation, though, it seems that no one wants their own
indentation style "until they're ready to apply the project conventions".

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

Depends on the quality of the maintainer's coffee (and of their fire breath).

> 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 feeling is that there are too many messages that show up when visiting
a file (many of which have to do with optional packages), and so such a
message is likely to get lost.  It would be in *Messages*, though, which
might be enough once our hacker notices that something is amiss.

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

Sure, why not; it's trivial to implement and to understand.  But it has to
default to t, because otherwise you'll never even know that there are
directory-locals that you're supposed to be seeing.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.