Allowing .dir-locals-N.el

Allowing .dir-locals-N.el

[Artur Malabarba]

Hi All,

I'd like to implement support for additional .dir-locals.el files.

This is very useful in VCS repositories, where the main .dir-locals.el
file is usually under version control. In this situation it's usually
not good for every single contributor to stick their own variables
inside .dir-locals.el.

With this feature, you can have additional files called
.dir-locals-1.el, .dir-locals-2.el, etc... and these will be read for
local variables as well.

I can hardcode a single filename (like .dir-locals-extra.el) or make
it a regexp like "\\.dir-locals-[0-9]+\\.el", whatever people prefer.


Cheers,
Artur

Re: Allowing .dir-locals-N.el

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

That's not a bad idea as long as the `C-h v` buffer shows what all
.dir-locals*.el files are affecting that variable in that buffer.

[-- Attachment #2: Type: text/html, Size: 155 bytes --]

Re: Allowing .dir-locals-N.el

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> That's not a bad idea as long as the `C-h v` buffer shows what all .
> dir-locals*.el files are affecting that variable in that buffer.

I like this idea. For example, Git allows you to ignore files via two file
within a project:

    .gitignore
    .git/info/exclude

This allows both a project exclusion, and a user exclusion. Since
.dir-locals.el is often used to set project-wide standards, it seems natural
to allow an override.

I'm not sure about detecting such extra files by a naming convention. I'd
rather see `dir-locals-file-alist' with the following customization:

    (list (list regexp (choice file function) boolean))

The REGEXP matches directories, the FILE specifies a `.dir-locals.el` file to
use for that directory (or FUNCTION to determine the file), plus a BOOLEAN
indicating whether the alist should continue to be searched -- or, if we reach
the end of the list, we should also read .dir-locals.el from the expected
location.

The list of of `.dir-locals.el` files found in this fashion would be loaded in
reverse, so that the first one matching can override anything from the others
(after the manner of CSS).

How does that sound?

John

Re: Allowing .dir-locals-N.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

On 4 Nov 2015 4:24 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
> How does that sound?

TBH, sounds like more than I'll have the energy to implement. :-)
But who knows... Might turn out easier than I expected.

[-- Attachment #2: Type: text/html, Size: 322 bytes --]

Re: Allowing .dir-locals-N.el

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 4 Nov 2015 4:24 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
>> How does that sound?
>
> TBH, sounds like more than I'll have the energy to implement. :-)
> But who knows... Might turn out easier than I expected.

Just use a pattern instead of a fixed name and apply in alphabetical
order.  That should not make the code significantly larger.

-- 
David Kastrup

Re: Allowing .dir-locals-N.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On 4 Nov 2015 7:24 pm, "David Kastrup" <dak@gnu.org> wrote:
>
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
> > On 4 Nov 2015 4:24 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
> >> How does that sound?
> >
> > TBH, sounds like more than I'll have the energy to implement. :-)
> > But who knows... Might turn out easier than I expected.
>
> Just use a pattern instead of a fixed name and apply in alphabetical
> order.  That should not make the code significantly larger.

Yes. That much I've actually written already.
I was referring to John's suggestion of a generalised variable.

[-- Attachment #2: Type: text/html, Size: 925 bytes --]

Re: Allowing .dir-locals-N.el

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> TBH, sounds like more than I'll have the energy to implement. :-) But who
> knows... Might turn out easier than I expected.

I'd be willing to help you bang it out next week. Maybe we can get together on
some medium and pair code it? I'm guessing it'll be around 20-50 lines, plus
testing the integration.

John

Re: Allowing .dir-locals-N.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On 4 Nov 2015 7:54 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> >>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
> > TBH, sounds like more than I'll have the energy to implement. :-) But
who
> > knows... Might turn out easier than I expected.
>
> I'd be willing to help you bang it out next week. Maybe we can get
together on
> some medium and pair code it? I'm guessing it'll be around 20-50 lines,
plus
> testing the integration.

Sure! Assuming I don't end up writing it before that. :-)

[-- Attachment #2: Type: text/html, Size: 759 bytes --]

Re: Allowing .dir-locals-N.el

[Ted Zlatanov]

On Wed, 04 Nov 2015 11:24:05 -0500 John Wiegley <jwiegley@gmail.com> wrote: 

JW> I'm not sure about detecting such extra files by a naming convention. I'd
JW> rather see `dir-locals-file-alist' with the following customization:

JW>     (list (list regexp (choice file function) boolean))

That seems really complicated for every use case I can imagine. Why not
just look for `.dir-locals*.el' and sort lexicographically? That
degrades gracefully to the current state of things.

Otherwise you're building an ELisp facility to load files to augment
ELisp options, and you may as well just use ELisp.

Ted

Re: Allowing .dir-locals-N.el

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> That seems really complicated for every use case I can imagine. Why not just
> look for `.dir-locals*.el' and sort lexicographically? That degrades
> gracefully to the current state of things.
>
> Otherwise you're building an ELisp facility to load files to augment ELisp
> options, and you may as well just use ELisp.

That's an awfully good point. I guess lexicographic makes the most sense, and
is what /etc/rc.d has been doing for ages.

John

Re: Allowing .dir-locals-N.el

[Artur Malabarba]

2015-11-05 20:01 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> That seems really complicated for every use case I can imagine. Why not just
>> look for `.dir-locals*.el' and sort lexicographically? That degrades
>> gracefully to the current state of things.

I've written and pushed a version of this to the branch
scratch/dir-local-wildcard

It allows wildcards in `dir-locals-file', and loads them in string<
order. That is, a file called ".dir-locals2.el" will override the
values in ".dir-locals.el" (only conflicting values are overridden).

Nicollas, this also adds a function `map-merge-with' to map.el. Is that alright?

Re: Allowing .dir-locals-N.el

[Eli Zaretskii]

> Date: Sat, 7 Nov 2015 13:01:30 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> 
> It allows wildcards in `dir-locals-file', and loads them in string<
> order.

Doesn't that mean ".dir-locals20.el: will be unable to override
".dir-locals3.el"?

Re: Allowing .dir-locals-N.el

[Ted Zlatanov]

On Sat, 07 Nov 2015 15:41:26 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> Date: Sat, 7 Nov 2015 13:01:30 +0000
>> From: Artur Malabarba <bruce.connor.am@gmail.com>
>> 
>> It allows wildcards in `dir-locals-file', and loads them in string<
>> order.

EZ> Doesn't that mean ".dir-locals20.el: will be unable to override
EZ> ".dir-locals3.el"?

Yes, lexicographical sorting means you'd use .dir-localsⅩⅩ.el or
.dir-locals⒛el :)

(For those without Unicode, the joke is that I use the Roman XX and the
NUMBER TWENTY PERIOD).

Ted

Re: Allowing .dir-locals-N.el

[Juri Linkov]

>>> It allows wildcards in `dir-locals-file', and loads them in string<
>>> order.
>
> EZ> Doesn't that mean ".dir-locals20.el: will be unable to override
> EZ> ".dir-locals3.el"?
>
> Yes, lexicographical sorting means you'd use .dir-localsⅩⅩ.el or
> .dir-locals⒛el :)

Then maybe better to compare using version< like we do with ChangeLog.[0-9]?

> (For those without Unicode

Unicode-impaired :)

> the joke is that I use the Roman XX and the NUMBER TWENTY PERIOD).

Re: Allowing .dir-locals-N.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

> > EZ> Doesn't that mean ".dir-locals20.el: will be unable to override
> > EZ> ".dir-locals3.el"?

Yes. I'm honestly not concerned with this. That's just how file sorting
works everywhere, from a simple “sorted-by-name” folder in Widows Explorer
all the way to the order in which config files are loaded inside
`/etc/*.d/' configuration directories. People might be caught off-guard by
this occasionally, but it's fairly easy to understand.

On 7 Nov 2015 10:34 pm, "Juri Linkov" <juri@linkov.net> wrote:
> Then maybe better to compare using version< like we do with
ChangeLog.[0-9]?

The pattern used to find dir locals is configurable and completely general.
We can't rely on the file name having any specific form whatsoever.
For instance, I'm setting the default value to .dir-locals*.el, but someone
could configure theirs to be .project*?local-vars*.el?.

In this context, I feel like it would be insane to try to find a general
sorting method more appropriate than string<.

The only alternative I see is to change the approach completely and not
allow wildcards in the custom-file variable. Instead, we could say that any
file whose name equals dir-locals-file appended with a dot and a number is
also a valid dir-locals. For instance .dir-locals.el.20.

Then we could use proper numeric (or version) sorting on these.

[-- Attachment #2: Type: text/html, Size: 1643 bytes --]

Re: Allowing .dir-locals-N.el

[Eli Zaretskii]

> Date: Sun, 8 Nov 2015 11:37:59 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > > EZ> Doesn't that mean ".dir-locals20.el: will be unable to override 
> > > EZ> ".dir-locals3.el"? 
> 
> Yes. I'm honestly not concerned with this. That's just how file sorting works
> everywhere, from a simple “sorted-by-name” folder in Widows Explorer all the
> way to the order in which config files are loaded inside `/etc/*.d/'
> configuration directories.

If this is a custom, then I'm okay with that.  Just don't forget to
document this subtle point.

Re: Allowing .dir-locals-N.el

[Stephen Leake]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> > EZ> Doesn't that mean ".dir-locals20.el: will be unable to override
>> > EZ> ".dir-locals3.el"?
>
> Yes. I'm honestly not concerned with this. That's just how file sorting
> works everywhere, from a simple “sorted-by-name” folder in Widows Explorer
> all the way to the order in which config files are loaded inside
> `/etc/*.d/' configuration directories. People might be caught off-guard by
> this occasionally, but it's fairly easy to understand.

The simple fix is for the user to use two digit numbers in all files;

.dir-locals03.el
.dir-locals20.el

That's entirely under the control of the user; if they have less than
ten files, use one digit; more than ten, two digits, etc.

-- 
-- Stephe

Re: Allowing .dir-locals-N.el

[John Wiegley]

>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:

> The simple fix is for the user to use two digit numbers in all files;
> .dir-locals03.el .dir-locals20.el

> That's entirely under the control of the user; if they have less than ten
> files, use one digit; more than ten, two digits, etc.

I agree, string< seems sufficient. I'm used to doing the double-digit thing in
lots of places on my system, and would be surprised by a more "intelligent"
ordering, actually. However, a customization variable might be a good thing,
since we have precedent for version< in other places. Just:

    (defcustom some-long-name #'string<
        <making version< an option>

John