unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Michał Nazarewicz" <mina86@mina86.com>
To: Alan Mackenzie <acm@muc.de>
Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org
Subject: Re: [PATCH] cc-mode: don't tread dir-local and file-local variables differently
Date: Mon, 25 May 2020 20:47:06 +0100	[thread overview]
Message-ID: <CA+pa1O2ng=Jy-UoskfhoUYcggd_w4kGxYBNdVrknjzXzpNjRyA@mail.gmail.com> (raw)
In-Reply-To: <20200525184412.GA8662@ACM>

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»


       reply	other threads:[~2020-05-25 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200512194516.83180-1-mina86@mina86.com>
     [not found] ` <20200513184745.GA8857@ACM>
     [not found]   ` <CA+pa1O2gKba9iHpPbQCf6PibY4gg57gj2ZjC4oTy4277i5pTzg@mail.gmail.com>
     [not found]     ` <20200517142327.GA12554@ACM>
     [not found]       ` <CA+pa1O2Yoqg9Kjy-Eh7K6RUtpDXpSfWOEW5EWduZVBgY5LK8QQ@mail.gmail.com>
     [not found]         ` <20200525184412.GA8662@ACM>
2020-05-25 19:47           ` Michał Nazarewicz [this message]
2020-05-26  2:13             ` [PATCH] cc-mode: don't tread dir-local and file-local variables differently 조성빈
2020-05-26  2:28             ` Stefan Monnier
2020-05-26 17:18               ` Alan Mackenzie
2020-05-28  2:21                 ` Stefan Monnier
2020-06-01  0:19                   ` Michał Nazarewicz
2020-06-01 13:29                     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+pa1O2ng=Jy-UoskfhoUYcggd_w4kGxYBNdVrknjzXzpNjRyA@mail.gmail.com' \
    --to=mina86@mina86.com \
    --cc=acm@muc.de \
    --cc=bug-cc-mode@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).