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»
next parent 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).