Re: [PATCH] cc-mode: don't tread dir-local and file-local variables differently

[Michał Nazarewicz]

>>> IIUC your example shows a different interaction between a global
>>> setting and file-vs-dir setting.  FWIW, I do find it surprising that
>>> file-local would be treated differently from dir-local when faced
>>> with a global setting.

>> They are treated consistently - where there are conflicting sources
>> for a particular parameter, that of the highest priority takes
>> precedence.

On Thu, 28 May 2020 at 03:21, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Maybe I misunderstood the example, but from the description I read
> there are 2 cases: one has "global + file-local" and the other has
> "global + dir-local".  So it seems those two cases should give the
> same result since the priority ordering for "global vs file-local" is
> the same as that for "global vs dir-local".
>
> Yet IIUC those two cases give different results, which would seem to
> imply that somewhere "global" takes precedence over either "file-local"
> or "dir-local", which I think would be wrong.

Correct.

The longer explanation is that if ‘c-file-style’ value comes from
a file-local variable, the specified style is set with DONT-OVERRIDE
equal nil.  If the value comes from a directory-local variable, the
style is set with DONT-OVERRIDE equal t.  In former case any global
customisation will be overridden; in the latter it won’t.

I’ve mentioned hooks earlier because it doesn’t matter if the value is
set via ‘setq-default’ in init.el, via customise or in one of cc-mode
hooks.  The end result is that a file-local ‘c-file-style’ will override
it while directory-local won’t.

On Tue, 26 May 2020 at 18:18, Alan Mackenzie <acm@muc.de> wrote:
> This was all worked out in 2009 in response to bug #3808.[1] I really
> don't think it a good idea to re-introduce bug #3808 by discarding
> its fix.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3808

Whether that report was a bug in the first place is disputable.  In that
issue, user set ‘c-cleanup-list’ via customise; why that should take
precedence over directory-local variables remains a mystery.

Significant use-case for file- and directory-local variables is for
projects to codify their coding style.  To do that effectively, those
variables need to override user-defaults.

Other solutions to user’s issue exist.  Most don’t require introducing
inconsistency in how file- and directory-local variables behave in
cc-mode.  For example, with the following files:

* init.el:               (setq-default indent-tabs-mode nil c-basic-offset 4)
* /tmp/a/.dir-locals.el: ((nil . ((c-file-style . "python"))))
* /tmp/a/foo.cc          // empty
* /tmp/b/.dir-locals.el: ;; non-existent
* /tmp/b/foo.cc          // -*- c-file-style: "python" -*-

opening /tmp/a/foo.cc results in:
* c-basic-offset equal to 4 (coming from defaults in init.el file),
* indent-tabs-mode equal to t (coming from "python" style); and
opening /tmp/b/foo.cc results in:
* c-basic-offset equal to 8 (coming from  "python" style) and
* indent-tabs-mode equal to t (coming from "python" style).

Arguably the real problem bug #3808 exposed is that "gnu" style does not
set ‘c-cleanup-list’ to include `space-before-funcall`.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»