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

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

[Michał Nazarewicz]

It’s clear that we won’t reach any kind of agreement any time soon, so
let me loop in emacs-devel in hope of looping more people in and
reaching some kind of consensus.

For those not subscribed to cc-mode-help, the thread can be followed
from the start at [1].

[1] https://sourceforge.net/p/cc-mode/mailman/cc-mode-help/thread/20200512194516.83180-1-mina86%40mina86.com/#msg37011452

To quickly recap, CC Mode treats ‘c-file-style’ differently depending on
whether it comes from .dir-locals.el or a file-local variable.  For
example, having the following in init.el:

    (setq-default 'c-basic-offset 4)

consider the following two scenarios:

1) /tmp/foo/.dir-locals.el exists and contains a single line:

       ((nil . ((c-file-style . "bsd"))))

   Opening an empty /tmp/foo/foo.c file results in ‘c-basic-offset’
   being four and ‘c-file-style’ being "bsd".

2) /tmp/bar/.dir-locals.el does not exist but /tmp/bar/bar.c does and
   contains a single line:

       /* -*- c-file-style: "bsd" -*- */

   Opening that file results in ‘c-basic-offset’ being eight and
   ‘c-file-style’ being "bsd".  (Value of eight for the offset comes
   from "bsd" style).

I maintain that in both cases ‘c-basic-offset’ should be the same.
I further maintain that its value should be eight.  Alan disagrees and
maintains that cc-mode-hook should overwrite settings in dir-local
variables but should be overwritten by settings in file-local variables.

> On Sun, May 24, 2020 at 22:08:36 +0100, Michał Nazarewicz wrote:
> > > On Sun, May 17, 2020 at 12:56:12 +0100, Michał Nazarewicz wrote:
> > >> That’s not what Emacs documentation says though.  From [1]:
>
> > >>>>> Whenever Emacs visits any file in that directory or any of its
> > >>>>> subdirectories, it will apply the directory-local variables
> > >>>>> specified in .dir-locals.el, as though they had been defined as
> > >>>>> file-local variables for that file (see File Variables).
>
> > >> [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html
>
> > It’s also sensible that file-local variables take precedence over
> > dir-local variables.  And no one would be surprised by that.

On Mon, 25 May 2020 at 19:44, Alan Mackenzie <acm@muc.de> wrote:
> Just as it is sensible that a hook setting takes precedence over a
> dir-local setting.

No, it doesn’t.  dir-local and file-local configuration is both located
closer to the file being open than settings specified in a hook.  Values
in a hook apply to anything user opens anywhere.  dir-local and
file-local variables are narrower in scope and thus should have higher
priority.

> > What is surprising though is that there is something in-between those
> > two levels because there’s never any indication of that.

> There's thousands of things about Emacs which aren't discussed on that
> page.  The workings of hook functions is just one of them.  Who wants to
> read a page stuffed full of boring barely relevant technicalities?

It’s highly relevant that c-file-style variable behave completely
different whether it’s dir-local or file-local.

> > On Sun, 17 May 2020 at 15:23, Alan Mackenzie <acm@muc.de> wrote:
> > >> That is, directory-local should behave ‘as though they had been’
> > >> file-local.
>
> > > No.  That just says they will be _applied_ as though they were file
> > > local.  And CC Mode currently does this.
>
> > CC Mode treats values from dir-local variables and file-local variables
> > differently.
>
> Only to the extent they are different.  As discussed above it is
> impossible to treat them the same, in particular when there are
> competing values for any configuration option.
>
> > It applies them the same way only in the sense that the ‘c-file-style’
> > symbol will be bound to the same value, however CC Mode won’t treat
> > that value the same.
>
> > You cannot say that CC Mode applies values of dir-local as though they
> > had been file-local if CC Mode explicitly differentiate its behaviour
> > based on where the value came from.
>
> I can, and I do.  Regardless of where the value comes from (there are
> about nine places) it is treated the same.

No, it is not.  If ‘c-file-style’ value comes from file-local variable
it is applied to the buffer in one way.  If ‘c-file-style’ value comes
from dir-local variable it’s applied in a different way.

> Only when there are competing values from different places does it get
> complicated.  Then the higher/highest priority setting "wins".

There are no competing values of ‘c-file-style’ variable.  In all
scenarios I’ve described the variable exists in only one place and its
value is "bsd".

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

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

[조성빈]

Michał Nazarewicz <mina86@mina86.com> 작성:

> To quickly recap, CC Mode treats ‘c-file-style’ differently depending on
> whether it comes from .dir-locals.el or a file-local variable.  For
> example, having the following in init.el:
>
>     (setq-default 'c-basic-offset 4)
>
> consider the following two scenarios:
>
> 1) /tmp/foo/.dir-locals.el exists and contains a single line:
>
>        ((nil . ((c-file-style . "bsd"))))
>
>    Opening an empty /tmp/foo/foo.c file results in ‘c-basic-offset’
>    being four and ‘c-file-style’ being "bsd".
>
> 2) /tmp/bar/.dir-locals.el does not exist but /tmp/bar/bar.c does and
>    contains a single line:
>
>        /* -*- c-file-style: "bsd" -*- */
>
>    Opening that file results in ‘c-basic-offset’ being eight and
>    ‘c-file-style’ being "bsd".  (Value of eight for the offset comes
>    from "bsd" style).
>
> I maintain that in both cases ‘c-basic-offset’ should be the same.
> I further maintain that its value should be eight.  Alan disagrees and
> maintains that cc-mode-hook should overwrite settings in dir-local
> variables but should be overwritten by settings in file-local variables.

As a user I think most people would expect the two results to be the same -  
the biggest use case of {dir,file}-local variables (at least known to me)  
is to maintain a consistent style between different Emacs customizations.

The person that added .dir-locals.el would have expected that all code  
inside this directory will follow the bsd-style — one should not have to  
consider various different customization scenarios and accommodate to them  
to have a consistent style.

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

[Stefan Monnier]

> 1) /tmp/foo/.dir-locals.el exists and contains a single line:
>
>        ((nil . ((c-file-style . "bsd"))))
>
>    Opening an empty /tmp/foo/foo.c file results in ‘c-basic-offset’
>    being four and ‘c-file-style’ being "bsd".
>
> 2) /tmp/bar/.dir-locals.el does not exist but /tmp/bar/bar.c does and
>    contains a single line:
>
>        /* -*- c-file-style: "bsd" -*- */
>
>    Opening that file results in ‘c-basic-offset’ being eight and
>    ‘c-file-style’ being "bsd".  (Value of eight for the offset comes
>    from "bsd" style).

I haven't thought very deeply about those two cases, so I'm not sure
whether I'd consider it a problem or a feature.

> I maintain that in both cases ‘c-basic-offset’ should be the same.
> I further maintain that its value should be eight.  Alan disagrees and
> maintains that cc-mode-hook should overwrite settings in dir-local
> variables but should be overwritten by settings in file-local variables.

Not sure what `cc-mode-hook` has to do with it since your above example
didn't use it.

>> Just as it is sensible that a hook setting takes precedence over a
>> dir-local setting.
> No, it doesn’t.  dir-local and file-local configuration is both located
> closer to the file being open than settings specified in a hook.  Values
> in a hook apply to anything user opens anywhere.  dir-local and
> file-local variables are narrower in scope and thus should have higher
> priority.

A hook setting can perform any test it likes to adjust the setting to
any detail of the situation.  So it is definitely more specific than
a dir-locals.el setting which applies blindly to all files underneath.

> It’s highly relevant that c-file-style variable behave completely
> different whether it’s dir-local or file-local.

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.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, May 25, 2020 at 22:28:15 -0400, Stefan Monnier wrote:

[ .... ]

> > It’s highly relevant that c-file-style variable behave completely
> > different whether it’s dir-local or file-local.

I think "completly different" here means "not identical".  The situation
we're in is one where there is no totally satisfactory solution.  We
could amend it the way the OP wants, but then hook functions would stop
working "properly", for example.

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

This was all worked out in 2009 in response to bug #3808.  (The exchange
in https://debbugs.gnu.org is short enough to be readable.)  I really
don't think it a good idea to re-introduce bug #3808 by discarding its
fix.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

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

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.

I don't have the time to reproduce it, let alone dig into it any
further, and in any case I'm sure you already know what I'm writing, so
I'll just presume there's either a misunderstanding on my side or on the
side of the OP.


        Stefan

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»

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

[Stefan Monnier]

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

It's OK for hooks to override dir-local settings.
It's more problematic when global settings override dir-local settings.


        Stefan