Rename .dir-locals.el to .dir-locals.eld

Rename .dir-locals.el to .dir-locals.eld

[Stefan Monnier]

I think we should restrict the `.el` extension for files which contain
actual ELisp code rather than files that just contain text in ELisp's
sexp format.

WDYT?


        Stefan

RE: [External] : Rename .dir-locals.el to .dir-locals.eld

[Drew Adams]

> I think we should restrict the `.el` extension for files which contain
> actual ELisp code rather than files that just contain text in ELisp's
> sexp format.  WDYT?

1. Why do you think so?

2. Isn't every Elisp sexp "code"?  How are you
   going to distinguish "code" from other sexps?

Re: [External] : Rename .dir-locals.el to .dir-locals.eld

[Stefan Monnier]

>> I think we should restrict the `.el` extension for files which contain
>> actual ELisp code rather than files that just contain text in ELisp's
>> sexp format.  WDYT?
>
> 1. Why do you think so?
>
> 2. Isn't every Elisp sexp "code"?  How are you
>    going to distinguish "code" from other sexps?

Again?  We already went through this discussion.  And the result is
`lisp-data-mode`, which the major mode I'd recommend we use for
`.eld` files.


        Stefan

Re: Rename .dir-locals.el to .dir-locals.eld

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think we should restrict the `.el` extension for files which contain
> actual ELisp code rather than files that just contain text in ELisp's
> sexp format.
>
> WDYT?

It would break things, so I'm against this kind of purely cosmetic
change.

I don't think anyone will accidentally load his .dir-locals.el, and not
much harm would come from that either.

Re: [External] : Rename .dir-locals.el to .dir-locals.eld

[Dmitry Gutov]

On 21.01.2022 01:14, Drew Adams wrote:
> 2. Isn't every Elisp sexp "code"?  How are you
>     going to distinguish "code" from other sexps?

Try 'M-x eval-buffer' in any buffer visiting a .dir-locals.el file.

Re: Rename .dir-locals.el to .dir-locals.eld

[Robin Tarsiger]

Stefan Monnier wrote:
> I think we should restrict the `.el` extension for files which contain
> actual ELisp code rather than files that just contain text in ELisp's
> sexp format.
> 
> WDYT?

I think it's a bit late to do that for .dir-locals.el given how many of
them are who-knows-where, but it'd be good to assign them lisp-data-mode
in auto-mode-alist (don't forget the -2 version) and establish a loose
policy of .eld for "read but not evaluated" files for the future.

More specifically to the first part, our only practical option is adding
more names, and the practical utility of the new ones stays questionable
for a long time. High churn and complexity for not much cleanliness. It's
already a special-looking file name, too.

-RTT

Re: [External] : Rename .dir-locals.el to .dir-locals.eld

[Robin Tarsiger]

Dmitry Gutov wrote:
> On 21.01.2022 01:14, Drew Adams wrote:
>> 2. Isn't every Elisp sexp "code"?  How are you
>>     going to distinguish "code" from other sexps?
> 
> Try 'M-x eval-buffer' in any buffer visiting a .dir-locals.el file.
> 

And I'll note in passing that both the Info node ‘(elisp)Intro Eval’
and the glossary of the Common Lisp HyperSpec find this idea common
enough to assign it a short name. A ‘form’ is an object meant to be
evaluated. Every form is an object, but not every object is a form
(depending on context). The separation of reading and evaluation
is also called out specifically in the above Info node, and there's
even a footnote which I read as unlinking the ‘sexp’ term from the
expectation of evaluation (but the context is ambiguous).

-RTT

Re: Rename .dir-locals.el to .dir-locals.eld

[Po Lu]

Robin Tarsiger <rtt@dasyatidae.com> writes:

> I think it's a bit late to do that for .dir-locals.el given how many of
> them are who-knows-where, but it'd be good to assign them lisp-data-mode
> in auto-mode-alist (don't forget the -2 version) and establish a loose
> policy of .eld for "read but not evaluated" files for the future.

I think auto-mode-alist is already set up to give .dir-locals.el files
`lisp-data-mode'.

RE: [External] : Rename .dir-locals.el to .dir-locals.eld

[Drew Adams]

> >> I think we should restrict the `.el` extension for files which contain
> >> actual ELisp code rather than files that just contain text in ELisp's
> >> sexp format.  WDYT?
> >
> > 1. Why do you think so?
> >
> > 2. Isn't every Elisp sexp "code"?  How are you
> >    going to distinguish "code" from other sexps?
> 
> Again?  We already went through this discussion.  And the result is
> `lisp-data-mode`, which the major mode I'd recommend we use for
> `.eld` files.

I see.  I just now found and read what I guess
is the thread `lisp-data-mode' was discussed in:

https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00692.html

(But the JavaScript/JSON analogy given there
isn't so exact here, I expect.  IIUC, in at
least some of the expected Lisp "data" files
any and all valid Elisp syntax is to be
expected.  Not all JavaScript syntax is JSON.)

What's the criterion for such data?  Is it
that it's Lisp-`read'able without error (not
necessarily `eval'able without error)?

I still have the question "Why?" for *.eld.
(That doesn't imply an objection to it.)
What's the reason for the different extension?

Is it just so flymake or font-lock or whatever
doesn't treat list sexps as more than lists,
i.e., as function applications?

Why, please, if you don't mind.

RE: [External] : Rename .dir-locals.el to .dir-locals.eld

[Drew Adams]

> > 2. Isn't every Elisp sexp "code"?  How are you
> >     going to distinguish "code" from other sexps?
> 
> Try 'M-x eval-buffer' in any buffer visiting a .dir-locals.el file.

Lisp data is Lisp code.  Lisp code can raise
errors.

Narrow any bit of fine Lisp code randomly and
eval it.  It's still code; it's just unlikely
to be `eval'able without error.

I think you're talking about Lisp code that's
Lisp-`read'able without error, but not 
necessarily `eval'able without error.

If so, fine.  But that, in itself, doesn't
say why it merits a different file extension.
There may be good reasons.  So far, haven't
heard any.

(Ask "Why?" around here and the knives come
out.  I'd think that a proposal to change a
file extension would be accompanied by a
simple reason or two...)

RE: [External] : Rename .dir-locals.el to .dir-locals.eld

[Drew Adams]

> And I'll note in passing that both the Info node ‘(elisp)Intro Eval’
> and the glossary of the Common Lisp HyperSpec find this idea common
> enough to assign it a short name. A ‘form’ is an object meant to be
> evaluated. Every form is an object, but not every object is a form
> (depending on context). The separation of reading and evaluation
> is also called out specifically in the above Info node, and there's
> even a footnote which I read as unlinking the ‘sexp’ term from the
> expectation of evaluation (but the context is ambiguous).

That's precisely the way to speak of it.
Readable without error, not necessarily
evalable without error.  That's one way
to gauge probable intention ("meant to
be", "expectation of evaluation").

Re: [External] : Rename .dir-locals.el to .dir-locals.eld

[Dmitry Gutov]

On 21.01.2022 05:04, Drew Adams wrote:
> I think you're talking about Lisp code that's
> Lisp-`read'able without error, but not
> necessarily `eval'able without error.

That's Lisp data.

Re: Rename .dir-locals.el to .dir-locals.eld

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 20 Jan 2022 13:31:24 -0500
> 
> I think we should restrict the `.el` extension for files which contain
> actual ELisp code rather than files that just contain text in ELisp's
> sexp format.
> 
> WDYT?

I don't like it: too little gain and too much noise.

Re: Rename .dir-locals.el to .dir-locals.eld

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think we should restrict the `.el` extension for files which contain
> actual ELisp code rather than files that just contain text in ELisp's
> sexp format.
>
> WDYT?

I think it makes sense logically, but I think it'd lead to too much
futzing about for the users, and people will end up with both .el and
.eld files.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [External] : Rename .dir-locals.el to .dir-locals.eld

[Michael Welsh Duggan]

Drew Adams <drew.adams@oracle.com> writes:

>> > 2. Isn't every Elisp sexp "code"?  How are you
>> >     going to distinguish "code" from other sexps?
>> 
>> Try 'M-x eval-buffer' in any buffer visiting a .dir-locals.el file.
>
> Lisp data is Lisp code.  Lisp code can raise
> errors.
>
> Narrow any bit of fine Lisp code randomly and
> eval it.  It's still code; it's just unlikely
> to be `eval'able without error.
>
> I think you're talking about Lisp code that's
> Lisp-`read'able without error, but not 
> necessarily `eval'able without error.
>
> If so, fine.  But that, in itself, doesn't
> say why it merits a different file extension.
> There may be good reasons.  So far, haven't
> heard any.

From my point of view, it is an indication that the lisp forms in the
file are not guaranteed to be (and most likely will not be) evaluated.
Having a separate mode means that buffers with this mode can
automatically avoid linting as if they were top level forms intended for
evaluation.  Having a separate extension makes it easy to automatically
use a different editing mode.  Also, the extension and mode are good
indicators to the user that any forms generally meant for evaluation
(like backquote) are not guaranteed to enter a context in which they
will be evaluated.

All of this is just my opinion.  I did not go back and reread the
discussion that led to lisp-data-mode.  I remember that I was swayed by
the reasons in that discussion, so the reasons I state above may not be
good enough to merit the change in your opinion.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

RE: [External] : Rename .dir-locals.el to .dir-locals.eld

[Drew Adams]

> > I think you're talking about Lisp code that's
> > Lisp-`read'able without error, but not
> > necessarily `eval'able without error.
> >
> > If so, fine.  But that, in itself, doesn't
> > say why it merits a different file extension.
> > There may be good reasons.  So far, haven't
> > heard any.
> 
> From my point of view, it is an indication that the lisp forms in the
> file are not guaranteed to be (and most likely will not be) evaluated.
> Having a separate mode means that buffers with this mode can
> automatically avoid linting as if they were top level forms intended for
> evaluation.  Having a separate extension makes it easy to automatically
> use a different editing mode.  Also, the extension and mode are good
> indicators to the user that any forms generally meant for evaluation
> (like backquote) are not guaranteed to enter a context in which they
> will be evaluated.
> 
> All of this is just my opinion.  I did not go back and reread the
> discussion that led to lisp-data-mode.  I remember that I was swayed by
> the reasons in that discussion, so the reasons I state above may not be
> good enough to merit the change in your opinion.

Thank you.  And congratulations on being the
first (and so far only) one to present reasons
in favor of the proposed file-extension change.

Seriously.  Whether it's the White House or
some other bike shed, saying why & why not
paint it green helps the discussion.