GNU bug report logs - #58506
Use ".dir-locals.eld" and ".dir-locals-2.eld" when they exist

Previous Next

Full log

Message #47 received at 58506 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 58506 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 Juri Linkov <juri <at> linkov.net>, Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#58506: Use ".dir-locals.eld" and ".dir-locals-2.eld" when
 they exist
Date: Sat, 15 Oct 2022 09:38:00 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> What I would like to see if some kind of extensibility in the syntax.
>> Perhaps using methods.  I have often seen projects using `eval' just
>> because the options they are setting are not trivial assignments, but
>> conventional modifications like prepending an item to a list or setting
>> a symbol property (check out the .dir-locals.el for Guix if you want to
>> see a massive "Do you want to accept all these variables" prompt).
>
> Yes, exactly -- people have to resort to using `eval' (which is
> something people should use as little as possible) because our syntax
> doesn't allow for simple things like adding values to a list.
>
> Post-mode variables and list concatenation are two things we'd like to
> have, but I'm sure there's a whole bunch of stuff people will come up
> with if the syntax allowed for (safe) extensions.
>
> I don't know what the new syntax would look like -- the current syntax
> is, er, very implementation-friendly and user-hostile.  I.e., it's easy
> for Emacs to parse, and difficult for people to write:
>
> ((nil . ((tab-width . 8)
>          (sentence-end-double-space . t)
>          (fill-column . 70)
> 	 (emacs-lisp-docstring-fill-column . 65)
>          (vc-git-annotate-switches . "-w")
>          (bug-reference-url-format . "https://debbugs.gnu.org/%s")
> 	 (diff-add-log-use-relative-names . t)))
>  (c-mode . ((c-file-style . "GNU")
>             (c-noise-macro-names . ("INLINE" "ATTRIBUTE_NO_SANITIZE_UNDEFINED" "UNINIT" "CALLBACK" "ALIGN_STACK"))
>             (electric-quote-comment . nil)
>             (electric-quote-string . nil)
>             (indent-tabs-mode . t)
> 	    (mode . bug-reference-prog))))

Since we are admitting that this is data (-> .eld), not code is it even
necessary to worry about how difficult it is two write.  Couldn't adding
a comment referencing `add-dir-local-variable', or if necessary some
other, new function be enough?

> Perhaps a more imperative style would be nice.  Err...  something
> like...
>
> (in-mode c-mode
>   (set c-file-style "GNU")
>   (set-early treesit-thing t)
>   (add-to-list odd-list 3)
>   (minor-mode indent-tabs-mode)
>   (minor-mode blink-parentheses-mode))

My only objection to "something like" this is that it appears to be Lisp
code, and people could get surprised when they try to add something that
isn't (eg. a regular `add-to-list' call that had a quote -- beginners
often get tripped up on these minor syntactic points).

> `safep' would have to be a bit adjusted -- a `safep' for `odd-list'
> would be (cl-every #'oddp) etc.
>
> And we'd make the parser backwards/forwards compatible -- i.e., elements
> that are unknown to the Emacs version running would just be ignored.

Ideally there would be a warning or some way you could find out that
variables aren't loaded, e.g. if you have a typo in
`blink-parenthesis-mode' vs. `blink-parentheses-mode'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.