Add a separate mode for .dir-locals.el

Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

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

Hi all,

.dir-locals.el files are currently opened in emacs-lisp-mode, but they are not proper Emacs Lisp files; as a result, Flymake generates incorrect diagnostics, and I don't know of an easy way to customize Emacs specifically for these files (there's is no hook that runs every time a dir-locals file is opened).  We've had a similar problem for a while in Flycheck.

The attached patch creates a trivial dir-locals-mode, derived from emacs-lisp-mode, and removes Flymake backends in that mode.

Thoughts?
Clément.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-separate-mode-for-.dir-locals.el-files.patch --]
[-- Type: text/x-patch; name="0001-Add-a-separate-mode-for-.dir-locals.el-files.patch", Size: 1809 bytes --]

From 9fec681101f27ec578cd25fa11fc737641b8dd91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Pit-Claudel?= <clement.pitclaudel@live.com>
Date: Wed, 16 Oct 2019 22:02:49 -0400
Subject: [PATCH] Add a separate mode for .dir-locals.el files

* lisp/progmodes/elisp-mode.el (dir-locals-mode): New mode; disable
  Flymake in it
* lisp/files.el (auto-mode-alist): Use it to open .dir-locals.el
---
 lisp/files.el                | 1 +
 lisp/progmodes/elisp-mode.el | 8 ++++++++
 2 files changed, 9 insertions(+)

diff --git a/lisp/files.el b/lisp/files.el
index 4b364b49d8..2f6d63ba1e 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -2657,6 +2657,7 @@ auto-mode-alist
      ("\\.ltx\\'" . latex-mode)
      ("\\.dtx\\'" . doctex-mode)
      ("\\.org\\'" . org-mode)
+     ("\\`\\.dir-locals\\(?:-2\\)?.el\\'" . dir-locals-mode)
      ("\\.el\\'" . emacs-lisp-mode)
      ("Project\\.ede\\'" . emacs-lisp-mode)
      ("\\.\\(scm\\|stk\\|ss\\|sch\\)\\'" . scheme-mode)
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 516e4f9cd6..fb704c7de0 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -259,6 +259,14 @@ emacs-lisp-mode
   (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
   (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile nil t))
 
+;;;###autoload
+(define-derived-mode dir-locals-mode emacs-lisp-mode "Directory locals"
+  "Major mode to edit .dir-locals.el files.
+
+\\{dir-locals-mode-map}"
+  (remove-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc t)
+  (remove-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile t))
+
 ;; Font-locking support.
 
 (defun elisp--font-lock-flush-elisp-buffers (&optional file)
-- 
2.17.1

Re: Add a separate mode for .dir-locals.el

[Lars Ingebrigtsen]

Clément Pit-Claudel <cpitcla@mit.edu> writes:

> The attached patch creates a trivial dir-locals-mode, derived from
> emacs-lisp-mode, and removes Flymake backends in that mode.
>
> Thoughts?

Makes sense to me.

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 17 Oct 2019 04:20:52 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Clément Pit-Claudel <cpitcla@mit.edu> writes:
> 
> > The attached patch creates a trivial dir-locals-mode, derived from
> > emacs-lisp-mode, and removes Flymake backends in that mode.
> >
> > Thoughts?
> 
> Makes sense to me.

Isn't it more logical for this to be solved in Flymake itself,
including letting users have Flymake enabled in their dir-locals
files?

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 03:53, Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 17 Oct 2019 04:20:52 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> Clément Pit-Claudel <cpitcla@mit.edu> writes:
>>
>>> The attached patch creates a trivial dir-locals-mode, derived from
>>> emacs-lisp-mode, and removes Flymake backends in that mode.
>>>
>>> Thoughts?
>>
>> Makes sense to me.
> 
> Isn't it more logical for this to be solved in Flymake itself,
> including letting users have Flymake enabled in their dir-locals
> files?

CC-ing João for an opinion.  My concern was mostly to give minor modes a clear signal that they can use to tell whether they are in proper emacs-lisp-mode, or in a dir-locals.el, as well as giving users a hook for .dir-locals.el files.

Re: Add a separate mode for .dir-locals.el

[João Távora]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2019-10-17 03:53, Eli Zaretskii wrote:
>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>> Date: Thu, 17 Oct 2019 04:20:52 +0200
>>> Cc: Emacs developers <emacs-devel@gnu.org>
>>>
>>> Clément Pit-Claudel <cpitcla@mit.edu> writes:
>>>
>>>> The attached patch creates a trivial dir-locals-mode, derived from
>>>> emacs-lisp-mode, and removes Flymake backends in that mode.
>>>>
>>>> Thoughts?
>>>
>>> Makes sense to me.
>> 
>> Isn't it more logical for this to be solved in Flymake itself,
>> including letting users have Flymake enabled in their dir-locals
>> files?
>
> CC-ing João for an opinion.  My concern was mostly to give minor modes
> a clear signal that they can use to tell whether they are in proper
> emacs-lisp-mode, or in a dir-locals.el, as well as giving users a hook
> for .dir-locals.el files.

I've missed the rest of the thread and don't have time to catch up right
now.  But AFAIR, one can set flymake-diagnostic-functions in file-local
variables.  So a .dir-locals.el file could have comment  trailer with its
own file-local variables.  If that's too meta, or too complicated, then
dir-locals-mode sounds pretty good to me too.

Actually it sounds better, because it's not exactly an emacs-lisp file,
you can't load or compile it, for one.

I don't know who proposed it, or what it meant exactly, but solving this
in Flymake directly sounds like hack.

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 17 Oct 2019 13:21:37 +0100
> Cc: emacs-devel@gnu.org
> 
> I don't know who proposed it, or what it meant exactly, but solving this
> in Flymake directly sounds like hack.

Why is that a hack?  Shouldn't Flymake "understand" the file it is
working on, including its syntax etc.?

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 09:16, Eli Zaretskii wrote:
>> From: João Távora <joaotavora@gmail.com>
>> Date: Thu, 17 Oct 2019 13:21:37 +0100
>> Cc: emacs-devel@gnu.org
>>
>> I don't know who proposed it, or what it meant exactly, but solving this
>> in Flymake directly sounds like hack.
> 
> Why is that a hack?

Flymake in ELisp mode is configured from emacs-lisp-mode, by adding two checkers to flymake-diagnostic-functions.  We could change that code to only add the hooks if the file name is not .dir-locals.el, but that seems less clean than creating a separate mode for .dir-locals.el files, since they aren't proper Emacs Lisp files.

> Shouldn't Flymake "understand" the file it is
> working on, including its syntax etc.?

In general, at least in Flycheck, we try to restrict that understanding to looking at which major-mode we are currently in (there are a few exceptions, like in sh-mode, where we look at the dialect using sh-shell, for example).

Re: Add a separate mode for .dir-locals.el

[Yuri Khan]

On Thu, 17 Oct 2019 at 21:57, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:

> Flymake in ELisp mode is configured from emacs-lisp-mode, by adding two checkers to flymake-diagnostic-functions.  We could change that code to only add the hooks if the file name is not .dir-locals.el, but that seems less clean than creating a separate mode for .dir-locals.el files, since they aren't proper Emacs Lisp files.

.dir-locals.el is not the only kind of an .el file that is not proper
Emacs Lisp code. Many modes store persistent data in the user’s
.emacs.d, in files ending in .el. Only some of those (e.g. recentf)
take extra steps to make that data valid code. Most just dump a data
structure and call it a day.

Maybe there should be a base major mode for S-expression files, and
emacs-lisp-mode, along with every other lisp-like mode, deriving from
that?

(There is a similar issue with Javascript vs JSON files, where the
former are code and the latter are data. Out-of-the-box, Emacs treats
them the same, with js-mode, though only some Javascript-related
things make sense in a JSON file, and certainly checks for data files
would be different.)

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 11:45, Yuri Khan wrote:
> On Thu, 17 Oct 2019 at 21:57, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
>> Flymake in ELisp mode is configured from emacs-lisp-mode, by adding two checkers to flymake-diagnostic-functions.  We could change that code to only add the hooks if the file name is not .dir-locals.el, but that seems less clean than creating a separate mode for .dir-locals.el files, since they aren't proper Emacs Lisp files.
> 
> .dir-locals.el is not the only kind of an .el file that is not proper
> Emacs Lisp code. Many modes store persistent data in the user’s
> .emacs.d, in files ending in .el. Only some of those (e.g. recentf)
> take extra steps to make that data valid code. Most just dump a data
> structure and call it a day.
> 
> Maybe there should be a base major mode for S-expression files, and
> emacs-lisp-mode, along with every other lisp-like mode, deriving from
> that?

Yes, that would be great. As far as I'm concerned, there's no reason to call these files .el, since most of the emacs-lisp-mode tools are not appropriate on such files.

Re: Add a separate mode for .dir-locals.el

[Amin Bandali]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

[...]
>
> Yes, that would be great. As far as I'm concerned, there's no reason
> to call these files .el, since most of the emacs-lisp-mode tools are
> not appropriate on such files.

+1.  Many other packages/files such as EBDB’s file-persistent database
could benefit from this, I think.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

[Sorry for the double mail, Eli]

On Thu, Oct 17, 2019 at 2:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Thu, 17 Oct 2019 13:21:37 +0100
> > Cc: emacs-devel@gnu.org
> >
> > I don't know who proposed it, or what it meant exactly, but solving this
> > in Flymake directly sounds like hack.
>
> Why is that a hack?  Shouldn't Flymake "understand" the file it is
> working on, including its syntax etc.?

In fact, no.  Not the new Flymake at least (and even in the old one I
have my doubts).  That is a job for mode-specific functions that hook
onto Flymake's interfaces.  They are known as Flymake backends and
usually place themselves in the local value of the
flymake-diagnostic-functions hook.  For lisp/elisp-mode.el, there are
two backends: elisp-flymake-byte-compile and elisp-flymake-checkdoc.

Maybe I misunderstood your suggestion: if you meant changing _those_ two
backends so that they notice they are in a dir-locals file and disable
themselves, then it's less bad.  But I you'd probably be adding more
complexity to progmodes/elisp-mode.el than you would (to the same file,
I guess) by setting up a trivial derived dir-locals-mode.  And having a
function that silently becomes a noop (the so-called "maybe" idiom) is
slightly hacky IMO.  But sometimes it's half-decent, I guess.

João

BTW, and on a tangent, a derived dir-locals-mode isn't the
bestoption. In OO, a derivation that _removes_functionality is a
no-no,it breaks "is a".  A better option would be to have a base
`lisp-prog-mode` and hen derive emacs-lisp-mode from it.  But that is
maybe impractical for other reasons and not justified by this case.

On Thu, Oct 17, 2019 at 2:16 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Thu, 17 Oct 2019 13:21:37 +0100
> > Cc: emacs-devel@gnu.org
> >
> > I don't know who proposed it, or what it meant exactly, but solving this
> > in Flymake directly sounds like hack.
>
> Why is that a hack?  Shouldn't Flymake "understand" the file it is
> working on, including its syntax etc.?
>


-- 
João Távora

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

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 17.10.2019 17:00, João Távora wrote:
> BTW, and on a tangent, a derived dir-locals-mode isn't the
> bestoption. In OO, a derivation that _removes_functionality is a
> no-no,it breaks "is a".  A better option would be to have a base
> `lisp-prog-mode` and hen derive emacs-lisp-mode from it.  But that is
> maybe impractical for other reasons and not justified by this case.

The lisp-mode-variables function does that job, more or less.

So one can just copy the emacs-lisp-mode definition, rename it to 
dir-local-mode and remove the unnecessary stuff (which will be at least 
a half of its definition).

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> BTW, and on a tangent, a derived dir-locals-mode isn't the
> bestoption.

I think it is, and you seem to agree below:

> A better option would be to have a base `lisp-prog-mode` and hen
> derive emacs-lisp-mode from it.

Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.


        Stefan

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

>> BTW, and on a tangent, a derived dir-locals-mode isn't the
>> bestoption.
>
> I think it is, and you seem to agree below:

I was unclear.  I wrote "derived dir-locals-mode", meaning the trivial
derivation from e-l-m proposed by someone (Lars? Clément?) isn't the
best option.

>> A better option would be to have a base `lisp-prog-mode` and hen
>> derive emacs-lisp-mode from it.
>
> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.

Yes.  Is this very hard to do?

João

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 11:41, João Távora wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> BTW, and on a tangent, a derived dir-locals-mode isn't the
>>> bestoption.
>>
>> I think it is, and you seem to agree below:
> 
> I was unclear.  I wrote "derived dir-locals-mode", meaning the trivial
> derivation from e-l-m proposed by someone (Lars? Clément?) isn't the
> best option.

>>> A better option would be to have a base `lisp-prog-mode` and hen
>>> derive emacs-lisp-mode from it.

I agree in principle; I did it that way to ensure that nothing would break.

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

>>> A better option would be to have a base `lisp-prog-mode` and hen
>>> derive emacs-lisp-mode from it.
>> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.
> Yes.  Is this very hard to do?

No, it should be straightforward.
Se sample patch below.


        Stefan
        

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 516e4f9cd63..da275bcae60 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -231,8 +231,16 @@ emacs-lisp-set-electric-text-pairs
           (setq-local electric-pair-text-pairs elisp-pairs)))))
   (remove-hook 'electric-pair-mode-hook #'emacs-lisp-set-electric-text-pairs))
 
+
+(define-derived-mode emacs-lisp-data-mode prog-mode "Emacs-Lisp-Data"
+  "Major mode for buffers holding data written in Emacs Lisp syntax."
+  :group 'lisp
+  (lisp-mode-variables nil nil 'elisp)
+  (setq-local electric-quote-string t)
+  (setq imenu-case-fold-search nil))
+
 ;;;###autoload
-(define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp"
+(define-derived-mode emacs-lisp-mode emacs-lisp-data-mode "Emacs-Lisp"
   "Major mode for editing Lisp code to run in Emacs.
 Commands:
 Delete converts tabs to spaces as it moves back.
@@ -241,15 +249,12 @@ emacs-lisp-mode
 \\{emacs-lisp-mode-map}"
   :group 'lisp
   (defvar project-vc-external-roots-function)
-  (lisp-mode-variables nil nil 'elisp)
   (add-hook 'after-load-functions #'elisp--font-lock-flush-elisp-buffers)
   (if (boundp 'electric-pair-text-pairs)
       (setq-local electric-pair-text-pairs
                   (append '((?\` . ?\') (?‘ . ?’))
                           electric-pair-text-pairs))
     (add-hook 'electric-pair-mode-hook #'emacs-lisp-set-electric-text-pairs))
-  (setq-local electric-quote-string t)
-  (setq imenu-case-fold-search nil)
   (add-function :before-until (local 'eldoc-documentation-function)
                 #'elisp-eldoc-documentation-function)
   (add-hook 'xref-backend-functions #'elisp--xref-backend nil t)

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

>>>> A better option would be to have a base `lisp-prog-mode` and hen
>>>> derive emacs-lisp-mode from it.
>>> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.
>> Yes.  Is this very hard to do?
>
> No, it should be straightforward.
> See sample patch below.

Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
buffers use emacs-lisp-data-mode by default?  We could reuse it for
other things other than dir-locals.

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Clément Pit-Claudel
>  <cpitclaudel@gmail.com>,  emacs-devel <emacs-devel@gnu.org>
> Date: Thu, 17 Oct 2019 18:04:26 +0100
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>>> A better option would be to have a base `lisp-prog-mode` and hen
> >>>> derive emacs-lisp-mode from it.
> >>> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.
> >> Yes.  Is this very hard to do?
> >
> > No, it should be straightforward.
> > See sample patch below.
> 
> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
> buffers use emacs-lisp-data-mode by default?  We could reuse it for
> other things other than dir-locals.

As I said, I don't want to introduce a major mode for this tiny
problem.  It's gross.

As for other things, I'm not sure that they matter (no one complained
about them yet), and I'm not sure we have a good idea of what exactly
does that entail.  If there's someone who wants to do the research and
suggest what, if anything, could or should be done for those other
files differently from emacs-lisp-mode, I'd welcome that, and we could
then talk about the best soltion(s).

Thanks.

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Clément Pit-Claudel
>>  <cpitclaudel@gmail.com>,  emacs-devel <emacs-devel@gnu.org>
>> Date: Thu, 17 Oct 2019 18:04:26 +0100
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> >>>> A better option would be to have a base `lisp-prog-mode` and hen
>> >>>> derive emacs-lisp-mode from it.
>> >>> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.
>> >> Yes.  Is this very hard to do?
>> >
>> > No, it should be straightforward.
>> > See sample patch below.
>> 
>> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
>> buffers use emacs-lisp-data-mode by default?  We could reuse it for
>> other things other than dir-locals.
>
> As I said, I don't want to introduce a major mode for this tiny
> problem.  It's gross.

If the problem is small but the best solution is equally small and
cheap, then I think you should consider it.  Stefan's solution isn't
gross at all, it's the most correct way to reuse code in this situation.

> As for other things, I'm not sure that they matter (no one complained
> about them yet),

I think Yuri just did, about lisp data files. Like Gnu's, for example,
or ido.el's or recentf's.

> and I'm not sure we have a good idea of what exactly does that entail.

Using Stefan's patch and adding some entries to auto-mode-alist?

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 18:42:32 +0100
> 
> >> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
> >> buffers use emacs-lisp-data-mode by default?  We could reuse it for
> >> other things other than dir-locals.
> >
> > As I said, I don't want to introduce a major mode for this tiny
> > problem.  It's gross.
> 
> If the problem is small but the best solution is equally small and
> cheap, then I think you should consider it.  Stefan's solution isn't
> gross at all, it's the most correct way to reuse code in this situation.

If you are going to disregard my opinion, why did you ask for it?

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 17 Oct 2019 18:42:32 +0100
>> 
>> >> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
>> >> buffers use emacs-lisp-data-mode by default?  We could reuse it for
>> >> other things other than dir-locals.
>> >
>> > As I said, I don't want to introduce a major mode for this tiny
>> > problem.  It's gross.
>> 
>> If the problem is small but the best solution is equally small and
>> cheap, then I think you should consider it.  Stefan's solution isn't
>> gross at all, it's the most correct way to reuse code in this situation.
>
> If you are going to disregard my opinion, why did you ask for it?

You asked summarily: "someone should do some research and find out what
it entails".  I simple gave an answer to those questions: use the small
patch by Stefan and add some entries to auto-mode-alist, starting with

So I didn't really disregard it, I simply advanced new arguments and am
asking you to reconsider.

Also, with all due respect, your "opinion" is less important to me than
the material reasons that you advance to justify it.  I just though
"it's gross" wasn't a sufficiently developed reason.

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 19:09:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: João Távora <joaotavora@gmail.com>
> >> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> >> Date: Thu, 17 Oct 2019 18:42:32 +0100
> >> 
> >> >> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
> >> >> buffers use emacs-lisp-data-mode by default?  We could reuse it for
> >> >> other things other than dir-locals.
> >> >
> >> > As I said, I don't want to introduce a major mode for this tiny
> >> > problem.  It's gross.
> >> 
> >> If the problem is small but the best solution is equally small and
> >> cheap, then I think you should consider it.  Stefan's solution isn't
> >> gross at all, it's the most correct way to reuse code in this situation.
> >
> > If you are going to disregard my opinion, why did you ask for it?
> 
> You asked summarily: "someone should do some research and find out what
> it entails".  I simple gave an answer to those questions: use the small
> patch by Stefan and add some entries to auto-mode-alist, starting with

See above: you asked whether I disagreed, I said I did, and you then
replied that you still think what I disagreed to was a good idea.

> So I didn't really disregard it, I simply advanced new arguments and am
> asking you to reconsider.

Stefan's patch is not a new argument, I've seen it before replying to
your question.

> Also, with all due respect, your "opinion" is less important to me than
> the material reasons that you advance to justify it.  I just though
> "it's gross" wasn't a sufficiently developed reason.

"Opinion", in quotes? really?  Thanks a lot, that's a great way to
enhance my motivation to continue being a co-maintainer for this
project.

"Gross" means that it solves the problem not where it is caused, and
thus makes the maintenance harder by spreading information far from
where it should be.  Who will remember that we introduced this mode
to fix that particular problem, and who will know that it may need to
be updated or removed, depending on the future development of Flymake?
No one will remember.

I suggested to look at the other similar files and try to describe
their common traits as a means to arrive at the decision whether we
might need some variant of ELisp mode for such files.  Just pointing
out that the files exist is not enough, as that doesn't give us enough
information for discussing such a mode.

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:
>> Also, with all due respect, your "opinion" is less important to me than
>> the material reasons that you advance to justify it.  I just though
>> "it's gross" wasn't a sufficiently developed reason.
> "Opinion", in quotes? really?  Thanks a lot, that's a great way to
> enhance my motivation to continue being a co-maintainer for this
> project.

I'm truly very sorry you interpreted it this way, and for the record I
think you're a great co-maintainer.  I didn't mean quotes to be meant in
a way that belittled your statement: you'll just have to believe me, I
meant them as in I was quoting you.  And I know "gross" has a precise
technical meaning in this list (I've seen you use it more often).

And I take the point that you don't like to be pressed and will not
insist beyond this point (except for a reply to your recent arguments,
of course).

> "Gross" means that it solves the problem not where it is caused, and
> thus makes the maintenance harder by spreading information far from
> where it should be.  Who will remember that we introduced this mode
> to fix that particular problem,

No need: we introduce this change to fix a class of problems, not a
particular one.  The particular situation regarding the
flymake-diagnostic-functions local happens to fit in that class.  It's a
symptom of misdesign, not a cause.  But others have suggested more
situations.  I don't think the same xref-backend-functions apply to
.dir-locals or ~/.emacs.d/recentf files for example.

> and who will know that it may need to be updated or removed, depending
> on the future development of Flymake?  No one will remember.

I don't understand: the exact same maintenance effort motivated by a
that hypothetical change to Flymake will be exerted whether we do this
change or don't.  That's easy to see from Stefan's patch: the same
number of mentions (2) to flymake-diagnostic-functions persist in the
exact same places where they did before, which is the major mode
function emacs-lisp-mode.  There is no duplication, inheritance is
linear and models "is a".

The only quite far-fetched scenario I could think up is if some code out
there actually relies on the fact that emacs-lisp-mode is derived
_directly_ from prog-mode.

Other than that, I really don't see drawbacks to this.  And, to state
the obvious, since I see drawbacks to the other solutions, I am for this
one.

> I suggested to look at the other similar files and try to describe
> their common traits as a means to arrive at the decision whether we
> might need some variant of ELisp mode for such files.

One common trait is being lisp data that is READable.  Another common
trait is being structured data, so syntax is the same, sexp navigation
automatically applies, as does electric-pair-mode, etc.  Basically,
whatever is in lisp-mode-variables, as someone pointed-out.  I think the
proposed name, emacs-lisp-data-mode, sums it up well.

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 20:00:38 +0100
> 
> I'm truly very sorry you interpreted it this way, and for the record I
> think you're a great co-maintainer.  I didn't mean quotes to be meant in
> a way that belittled your statement: you'll just have to believe me, I
> meant them as in I was quoting you.  And I know "gross" has a precise
> technical meaning in this list (I've seen you use it more often).

OK.

> > "Gross" means that it solves the problem not where it is caused, and
> > thus makes the maintenance harder by spreading information far from
> > where it should be.  Who will remember that we introduced this mode
> > to fix that particular problem,
> 
> No need: we introduce this change to fix a class of problems, not a
> particular one.

Which class of problems is that?  I see only one problem that was
clearly identified and described: the .dir-locals.el file, and the
problem is that Flymake erroneously reports problems in that file.

What other problems are clearly described like this one?

> The particular situation regarding the flymake-diagnostic-functions
> local happens to fit in that class.  It's a symptom of misdesign,
> not a cause.

What misdesign is that?

> But others have suggested more situations.  I don't think the same
> xref-backend-functions apply to .dir-locals or ~/.emacs.d/recentf
> files for example.

I don't think I understand what you are saying here.  Can we step back
a notch and start by describing the problem in more detail?  What
diagnostics does Flymake produce in the case of .dir-locals.el, and
why does it produce that diagnostics?

> > and who will know that it may need to be updated or removed, depending
> > on the future development of Flymake?  No one will remember.
> 
> I don't understand: the exact same maintenance effort motivated by a
> that hypothetical change to Flymake will be exerted whether we do this
> change or don't.

No, because this new mode is defined in a place that is not Flymake.
So when some change is done in Flymake that affects that mode, someone
needs to remember to update an unrelated mode in an unrelated source
file.

> That's easy to see from Stefan's patch: the same
> number of mentions (2) to flymake-diagnostic-functions persist in the
> exact same places where they did before, which is the major mode
> function emacs-lisp-mode.  There is no duplication, inheritance is
> linear and models "is a".

Stefan's patch doesn't mention anything related to Flymake, so I don't
understand what you are trying to say here.

> Other than that, I really don't see drawbacks to this.  And, to state
> the obvious, since I see drawbacks to the other solutions, I am for this
> one.

What drawbacks do you see in the other solution?  I see only
advantages.

> > I suggested to look at the other similar files and try to describe
> > their common traits as a means to arrive at the decision whether we
> > might need some variant of ELisp mode for such files.
> 
> One common trait is being lisp data that is READable.

I don't think I see how this is relevant to major modes.  Emacs major
modes don't care whether the text is readable by some interpreter or
not (and any Emacs Lisp is also readable, btw).  Emacs major modes
care about syntax.

> Another common trait is being structured data, so syntax is the
> same, sexp navigation automatically applies, as does
> electric-pair-mode, etc.  Basically, whatever is in
> lisp-mode-variables, as someone pointed-out.  I think the proposed
> name, emacs-lisp-data-mode, sums it up well.

You are basically saying that emacs-lisp-mode should do for these
files.  Which is what we use now.

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> What drawbacks do you see in the other solution?  I see only
> advantages.

I must admit that I don't know what "other solution" you're referring to.


        Stefan

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: João Távora <joaotavora@gmail.com>,
>   cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 15:53:17 -0400
> 
> > What drawbacks do you see in the other solution?  I see only
> > advantages.
> 
> I must admit that I don't know what "other solution" you're referring to.

It was mentioned up-thread:

  > In fact, no.  Not the new Flymake at least (and even in the old one I
  > have my doubts).  That is a job for mode-specific functions that hook
  > onto Flymake's interfaces.  They are known as Flymake backends and
  > usually place themselves in the local value of the
  > flymake-diagnostic-functions hook.  For lisp/elisp-mode.el, there are
  > two backends: elisp-flymake-byte-compile and elisp-flymake-checkdoc.
  > 
  > Maybe I misunderstood your suggestion: if you meant changing _those_ two
  > backends so that they notice they are in a dir-locals file and disable
  > themselves, then it's less bad.

  That could be an okay solution, I think.

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

>> > What drawbacks do you see in the other solution?  I see only
>> > advantages.
>> I must admit that I don't know what "other solution" you're referring to.
> It was mentioned up-thread:
>
>   > In fact, no.  Not the new Flymake at least (and even in the old one I
>   > have my doubts).  That is a job for mode-specific functions that hook
>   > onto Flymake's interfaces.  They are known as Flymake backends and
>   > usually place themselves in the local value of the
>   > flymake-diagnostic-functions hook.  For lisp/elisp-mode.el, there are
>   > two backends: elisp-flymake-byte-compile and elisp-flymake-checkdoc.
>   > 
>   > Maybe I misunderstood your suggestion: if you meant changing _those_ two
>   > backends so that they notice they are in a dir-locals file and disable
>   > themselves, then it's less bad.
>
>   That could be an okay solution, I think.

In the absence of a patch, it's hard to judge how clean or gross this
would be.


        Stefan

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Thu, Oct 17, 2019, 20:21 Eli Zaretskii <eliz@gnu.org> wrote:

>
> Which class of problems is that?  I see only one problem that was
> clearly identified and described: the .dir-locals.el file, and the
> problem is that Flymake erroneously reports problems in that file.
>

The class can informally be described by "functionality not applicable and
thus harmful to the manipulation of non-code lisp data files."

What misdesign is that?
>

A failure to correctly model the differences between lisp code and lisp
data. It's not a giant flaw, tho: inheritance is available and this is a
textbook example of where it should used.

> But others have suggested more situations.  I don't think the same
> > xref-backend-functions apply to .dir-locals or ~/.emacs.d/recentf
> > files for example.
>
> I don't think I understand what you are saying here.  Can we step back
> a notch and start by describing the problem in more detail?  What
> diagnostics does Flymake produce in the case of .dir-locals.el, and
> why does it produce that diagnostics?
>

I haven't checked, but if I had to guess, I would say it tries to invoke
the byte-compiler on the file, which doesn't make any sense, as you know.
As a result, bogus diagnostics are produced.

No, because this new mode is defined in a place that is not Flymake.
> So when some change is done in Flymake that affects that mode, someone
> needs to remember to update an unrelated mode in an unrelated source
> file.
>

No. Simply no. We might be miscommunicating, but when a change happens in
Flymake, the new mode proposed by Stefan need not be changed. At all.

Stefan's patch doesn't mention anything related to Flymake, so I don't
> understand what you are trying to say here.
>

Exactly. Stefan's patch doesn't change anything related to Flymake and
indeed solves the problem (or as i said, the class of problems where this
one related to Flymake happens to be included). And that is why it is very
good and you should take it! Indeed it answers your very legitimate
concerns about maintenance.

What drawbacks do you see in the other solution?  I see only
> advantages.
>

The least bad one  has code duplication, is less maintainable is specific
to Flymake.

You are basically saying that emacs-lisp-mode should do for these
> files.
>

No. I'm saying that it does a superset of what it should do. And that the
surplus is harmful. You can see exactly what that surplus is: it's whatever
is left in emacs-lisp-mode in Stefan's patch.

João

>

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 17 Oct 2019 22:35:33 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	emacs-devel@gnu.org
> 
>  Which class of problems is that?  I see only one problem that was
>  clearly identified and described: the .dir-locals.el file, and the
>  problem is that Flymake erroneously reports problems in that file.
> 
> The class can informally be described by "functionality not applicable and thus harmful to the manipulation of
> non-code lisp data files."

We already handle this in several places by explicitly exempting
.dir-locals.el from some operations that make no sense with it.  Why
ios this problem different?

>  What misdesign is that?
> 
> A failure to correctly model the differences between lisp code and
> lisp data.

There is no difference, not in general, not in Lisp.

>  I don't think I understand what you are saying here.  Can we step back
>  a notch and start by describing the problem in more detail?  What
>  diagnostics does Flymake produce in the case of .dir-locals.el, and
>  why does it produce that diagnostics?
> 
> I haven't checked, but if I had to guess, I would say it tries to invoke the byte-compiler on the file, which
> doesn't make any sense, as you know. As a result, bogus diagnostics are produced.

The byte compiler already knows to ignore .dir-locals.el, at least in
one of its commands.  If this is the only problem, maybe we need to
add that exemption in a couple of more places.

So I think we do need a detailed description of the problem, because
otherwise I think this discussion might be based on different
perceptions of what the problem is, and thus we have no common ground
for assessing the proposed solutions.

>  No, because this new mode is defined in a place that is not Flymake.
>  So when some change is done in Flymake that affects that mode, someone
>  needs to remember to update an unrelated mode in an unrelated source
>  file.
> 
> No. Simply no. We might be miscommunicating, but when a change happens in Flymake, the new mode
> proposed by Stefan need not be changed. At all.

I don't think I agree.  If Flymake is modified to do some meaningful
checks of .dir-locals.el, we may wish to remove this special major
mode as not needed anymore.

Anyway, I think this discussion needs to have a detailed description
of the problem, before we can continue talking about solutions.

Re: Add a separate mode for .dir-locals.el

[Juanma Barranquero]

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

On Fri, Oct 18, 2019 at 10:11 AM Eli Zaretskii <eliz@gnu.org> wrote:

> The byte compiler already knows to ignore .dir-locals.el, at least in
> one of its commands.

[Slightly aside:]

Too late now, but perhaps .dir-locals.el should have not used the .el
extension. Perhaps we should've reserved .el for lisp code (in the usual
meaning of the term).

 .dir-locals.el is just a configuration file, even if it contains elisp
data. .emacs.desktop is a save file containing real elisp code (I mean,
function calls like setq and desktop-create-buffer, not just data lists)
and it's not called .emacs-desktop.el, after all. As a consequence, I
imagine, of nobody usually either editing or directly loading
.emacs.desktop (though I've edited it a few times).

[On topic:]

I think I agree with Eli. It would perhaps make sense to have (in the
distribution, or in ELPA) a general mode to edit lisp data with all the
bells & whistles, and if so, its facilities would likely influence the way
other elisp data files are designed in the future. But a mode just to edit
one specific file type seems too much complexity for too little gain.

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

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> I think I agree with Eli. It would perhaps make sense to have (in the
> distribution, or in ELPA) a general mode to edit lisp data with all the
> bells & whistles, and if so, its facilities would likely influence the way
> other elisp data files are designed in the future. But a mode just to edit
> one specific file type seems too much complexity for too little gain.

The patch I sent creates an emacs-lisp-data-mode, not a dir-locals-file mode.
We could create a dir-locals-mode on top of it, but indeed I think it'd
only make sense if/when we decide to put functionality into it that's
specific to .dir-locals.el files.


        Stefan

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> We already handle this in several places by explicitly exempting
> .dir-locals.el from some operations that make no sense with it.  Why
> ios this problem different?

It's not.  It's a symptom of the same problem we've been avoiding by
sprinkling explicit exemption of a particular data-type in several
places.

> There is no difference, not in general, not in Lisp.

But there is.  As Richard put it, code is data, but data not necessarily
code.

> The byte compiler already knows to ignore .dir-locals.el, at least in
> one of its commands.  If this is the only problem, maybe we need to
> add that exemption in a couple of more places.

That's a worse solution because sprinkling exceptions around the code
creates exactly the "fragmentation" problems that you and Alan seem
intent on avoiding (and rightly so, I add).

Now maybe in those other situations you mentioned, you didn't have a
powerful enough abstraction already in place to avoid the sprinkling.
But in this case you do: derived major modes and buffer-local values.

> I don't think I agree.  If Flymake is modified to do some meaningful
> checks of .dir-locals.el, we may wish to remove this special major
> mode as not needed anymore.

As an aside, I'd like to point out that while you object to Stefans'
"arguments from the future", you provide the same kind of arguments.
Which is perfectly fine for me: anticipating the future is what good
design is about.

To your point: no, no not really.  First, Flymake does **not** need to
be modified to do meaningful checks of .dir-locals.el, or any other type
of file for that matter.  That is a fundamental misunderstanding that I
don't think we've cleared yet.  Like xref.el, project.el, and many
others, it's designed in such a way that extending it to work with a new
data type doesn't require touching the base library in any way.

But, to your concrete example: say you installed Stefan's patch and you
happen to write a Flymake backend (as per the manual/docstrings) for
meaningful dir-locals checks, call that backend
'elis-dir-locals-checker'.  You take this line:

  (add-to-list 'auto-mode-alist '( ".dir-locals.el" . emacs-lisp-data-mode))

And change it to read:

  (add-to-list 'auto-mode-alist '( ".dir-locals.el" . dir-locals-mode))

Then you add these lines

  (define-derived-mode dir-locals-mode emacs-lisp-data-mode "dir-locals"
    (add-to-list 'flymake-diagnostic-functions 'elis-dir-locals-checker nil t))

> Anyway, I think this discussion needs to have a detailed description
> of the problem, before we can continue talking about solutions.

I've done by best.

But I agree like 90% with you when you say "a serious problem didn't
start this thread".  It's true, but that problem is a symptom of bad
design.  Emacs lisp has the exact tool for the job here, we should use
it.  Perhaps you are thinking: "Why just not add the (if (string=
(buffer-file-name) dir-locals-file) ...) wherever and go on with your
life?"  But I am thinking exactly the same about Stefan's patch.

João

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 18 Oct 2019 11:25:17 +0100
> 
> > Anyway, I think this discussion needs to have a detailed description
> > of the problem, before we can continue talking about solutions.
> 
> I've done by best.

Where?  Maybe I've missed that, so please summarize it for me.  The
last I heard from you on this was that you didn't yet look seriously
at the particular problem, and that you thought it was due to byte
compilation.  Is there something more specific?

> But I agree like 90% with you when you say "a serious problem didn't
> start this thread".  It's true, but that problem is a symptom of bad
> design.  Emacs lisp has the exact tool for the job here, we should use
> it.  Perhaps you are thinking: "Why just not add the (if (string=
> (buffer-file-name) dir-locals-file) ...) wherever and go on with your
> life?"  But I am thinking exactly the same about Stefan's patch.

I would like to proceed to pretesting Emacs 27.1 and releasing it, so
I would like to avoid any changes that are not strictly needed.
Please help me in this.

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 18 Oct 2019 11:25:17 +0100
>> 
>> > Anyway, I think this discussion needs to have a detailed description
>> > of the problem, before we can continue talking about solutions.
>> I've done by best.
> Where?  Maybe I've missed that, so please summarize it for me.

Where?  Ufff... OK.  In this thread, I've been trying to tell, you many
times over, constructively, that I think this is a _symptom_ of a larger
problem, namely a failure to correctly model differences between lisp
code and data.  Nevertheless here is, one last time, for your benefit
(and hopefully ours, too), a summary:

- The starting complaint is that Flymake doesn't make sense for
  dir-locals.el, IOW you get bogus and distracting diagnostics for these
  dir-locals.el (by the way, the possibility of witnessing this for
  yourself, is exactly one M-x flymake-mode RET away from your fingers);

- But the problem also probably impacts whoever has no option but to add
  things to `emacs-lisp-mode-hook` that don't pertain to emacs-lisp
  data, but only emacs-lisp programs.  Modes such as Flycheck or
  which-func-mode or whatever people have in their .emacs;

- And we've also had others mention that this doesn't happen just for
  dir-locals.el files but also others such as recentf, tramp, ido files,
  and probably many other specialized data files that arent in Emacs
  core.  The problem here is, whenever people try structuredly edit
  these files they realize all they have is emacs-lisp-mode;

- Also, I've explained over and over that Flymake, or even its
  elisp-mode.el backends, aren't the culprit here: they apply cleanly to
  any emacs-lisp program, but not dir-locals.el because it does not
  contain an emacs-lisp program.  The mode is being misapplied to that
  file.

- Then I proceeded to explain the merits of Stefan's solution again and
  again, rebutting your "arguments from the future" with actual
  examples.

So here, once again, to summarize, are the two best solutions:

A) in lisp/progmodes/elisp-mode.el we do this

    -  (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
    -  (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile nil t))
    +  (unless (equal (buffer-file-name) dir-locals-file)
    +    (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
    +    (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile nil t)))

B) in lisp/progmodes/elisp-mode.el we do this

    -(define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp"
    +(add-to-list 'auto-mode-alist '(".?dir-locals.el" . emacs-lisp-data-mode))
    +;;;###autoload
    +(define-derived-mode emacs-lisp-data-mode prog-mode "Emacs-Lisp-Data"
    +  "Major mode for buffers holding data written in Emacs Lisp syntax."
    +  :group 'lisp
    +  (lisp-mode-variables nil nil 'elisp)
    +  (setq-local electric-quote-string t)
    +  (setq imenu-case-fold-search nil))
    +
    +;;;###autoload
    +(define-derived-mode emacs-lisp-mode emacs-lisp-data-mode "Emacs-Lisp"
       "Major mode for editing Lisp code to run in Emacs.
     Commands:
     Delete converts tabs to spaces as it moves back.
    @@ -241,15 +251,12 @@ emacs-lisp-mode
     \\{emacs-lisp-mode-map}"
       :group 'lisp
       (defvar project-vc-external-roots-function)
    -  (lisp-mode-variables nil nil 'elisp)
       (add-hook 'after-load-functions #'elisp--font-lock-flush-elisp-buffers)
       (if (boundp 'electric-pair-text-pairs)
           (setq-local electric-pair-text-pairs
                       (append '((?\` . ?\') (?‘ . ?’))
                               electric-pair-text-pairs))
         (add-hook 'electric-pair-mode-hook #'emacs-lisp-set-electric-text-pairs))
    -  (setq-local electric-quote-string t)
    -  (setq imenu-case-fold-search nil)
       (add-function :before-until (local 'eldoc-documentation-function)

"A" will probably fix the OP's problem it, but will run into problems if
someone has stuff in their emacs-lisp-mode-hook in the conditions I
explained above.

"B" always fixes the problem, is cheap and solves the other problems
described above, creating something that people have been asking for in
the process: a major mode to conveniently edit lisp data or from which
to safely derive specialized lisp data editing modes.

> last I heard from you on this was that you didn't yet look seriously
> at the particular problem, and that you thought it was due to byte
> compilation.  Is there something more specific?
>
>> But I agree like 90% with you when you say "a serious problem didn't
>> start this thread".  It's true, but that problem is a symptom of bad
>> design.  Emacs lisp has the exact tool for the job here, we should use
>> it.  Perhaps you are thinking: "Why just not add the (if (string=
>> (buffer-file-name) dir-locals-file) ...) wherever and go on with your
>> life?"  But I am thinking exactly the same about Stefan's patch.
>
> I would like to proceed to pretesting Emacs 27.1 and releasing it, so
> I would like to avoid any changes that are not strictly needed.
> Please help me in this.

I've been trying.  Up there are two summarized diffs.  Do this: if we've
already branched 27.1 (have we?) then I suggest A goes to the release
branch with a "dont merge" thingy and B goes into master.  But if you
read B carefully (and it's really not hard, it's 15 lines of change)
you'll arrive at the conclusion that it's pretty safe.  Your choice.

João

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 18.10.2019 16:43, João Távora wrote:
> "B" always fixes the problem, is cheap and solves the other problems
> described above, creating something that people have been asking for in
> the process: a major mode to conveniently edit lisp data or from which
> to safely derive specialized lisp data editing modes.

+1

Similar to how we both have js-mode and json-mode. The latter is a 
third-party package, but still.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 18 Oct 2019 14:43:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: João Távora <joaotavora@gmail.com>
> >> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> >> Date: Fri, 18 Oct 2019 11:25:17 +0100
> >> 
> >> > Anyway, I think this discussion needs to have a detailed description
> >> > of the problem, before we can continue talking about solutions.
> >> I've done by best.
> > Where?  Maybe I've missed that, so please summarize it for me.
> 
> Where?  Ufff... OK.  In this thread, I've been trying to tell, you many
> times over, constructively, that I think this is a _symptom_ of a larger
> problem, namely a failure to correctly model differences between lisp
> code and data.  Nevertheless here is, one last time, for your benefit
> (and hopefully ours, too), a summary:

Thanks, but I didn't ask for a summary, I asked for a detailed
description of the original problem which started this thread.

Clément, you've reported the original problem, so could you please
tell more details about it?  What triggers the problem, and how does
it manifest itself to the user?  Is it just due to an attempt to
byte-compile .dir-locals.el, or is it due to something else Flymake
does?  Thanks.

Re: Add a separate mode for .dir-locals.el

[João Távora]

[-- Attachment #1.1: Type: text/plain, Size: 2234 bytes --]

On Sat, Oct 19, 2019 at 10:52 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks, but I didn't ask for a summary, I asked for a detailed
> description of the original problem which started this thread.

Really?  Let me quote you:

> > > Where?  Maybe I've missed that, so please summarize it for me.
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now let me quote an exchange from two days ago:

> > >  EZ: Can we step back a notch and start by describing the problem in
> > >  EZ: more detail?  What diagnostics does Flymake produce in the case
> > >  EZ: of .dir-locals.el, and why does it produce that diagnostics?
> > JT: I haven't checked, but if I had to guess, I would say it tries to
invoke
> > JT: the byte-compiler on the file, which doesn't make any sense, as you
> > JT: know. As a result, bogus diagnostics are produced.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's it. Try it. It's not complicated at all. Type M-x flymake-mode
RET in a dir-locals buffer, you get bogus diagnostics because the wrong
flymake checker is being applied to the file.  I even attach a
screeshot.

The expected behaviour, in the absence of a proper dir-locals checker,
would be that (1) Flymake didn't turn itself on at all in these files or
(2) It didn't use the wrong backends.

And Clément also mentioned the same problem happens with Flycheck, a
package that is not in Emacs, but is very popular.  And the reason is
exactly the same: Flycheck hooks onto `emacs-lisp-mode-hook' (or uses
some equivalent mechanism) and produces bogus diagnostics for a
dir-locals.el, a file that is not an emacs-lisp-program.

It's really not complicated at all.

> Creating a major mode for this issue is like shooting sparrows with
> cannons.  Why not extend emacs-lisp-mode to DTRT with
> data-that-doesn't-make-sense-as-code instead?

That is _exactly_ what Clément proposed in his original patch.  It's
better than the "just hack Flymake" solution, it isn't ideal because it
relies on us (or the user) remembering to _undo_ whatever he (or we) add
to emacs-lisp-mode (or emacs-lisp-mode-hook) that doesn't work for
"data-that-doesn't-make-sense-as-code".

João

[-- Attachment #1.2: Type: text/html, Size: 2573 bytes --]

[-- Attachment #2: Screenshot 2019-10-19 at 11.56.42.png --]
[-- Type: image/png, Size: 30489 bytes --]

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

> The expected behaviour, in the absence of a proper dir-locals checker,
> would be that (1) Flymake didn't turn itself on at all in these files or
> (2) It didn't use the wrong backends.

A small followup, a piece of the puzzle you might be missing.  Flymake,
by default, doesn't "turn itself on" in emacs-lisp-mode buffers.  But
people add this line to their init files so that it does:

   (add-hook 'emacs-lisp-mode-hook 'flymake-mode)

...as they probably also do with Flycheck, and any other stuff they like
to use when coding elisp.

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 19 Oct 2019 12:00:10 +0100
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> > > >  EZ: Can we step back a notch and start by describing the problem in
> > > >  EZ: more detail?  What diagnostics does Flymake produce in the case
> > > >  EZ: of .dir-locals.el, and why does it produce that diagnostics?
> > > JT: I haven't checked, but if I had to guess, I would say it tries to invoke
> > > JT: the byte-compiler on the file, which doesn't make any sense, as you
> > > JT: know. As a result, bogus diagnostics are produced.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I thought it was just a guess, and I wanted us to be sure.  Are we
sure the problem is triggered by an attempt to invoke the byte
compiler on the file?

> > Creating a major mode for this issue is like shooting sparrows with
> > cannons.  Why not extend emacs-lisp-mode to DTRT with
> > data-that-doesn't-make-sense-as-code instead?
> 
> That is _exactly_ what Clément proposed in his original patch.

My understanding is that Clément proposed a new major mode.

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-19 07:56, Eli Zaretskii wrote:
> I thought it was just a guess, and I wanted us to be sure.  Are we
> sure the problem is triggered by an attempt to invoke the byte
> compiler on the file?

Yes, that is absolutely right: the byte-compiler, and checkdoc.  Both are invoked by Flymake and Flycheck because they apply their default "emacs-lisp-mode" behavior to .dir-locals.el files.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Sat, Oct 19, 2019 at 12:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I thought it was just a guess, and I wanted us to be sure.  Are we
> sure the problem is triggered by an attempt to invoke the byte
> compiler on the file?

It was a guess because another Flymake backend, such as checkdoc, could
have been producing similar bogus data.  I also didn't try Flycheck.
Anyway the guess is confirmed for Flymake, though apparently for
Flycheck the problem also extends to its checkdoc checker.

Here, "checker" ~== "backend" BTW.

> > > Creating a major mode for this issue is like shooting sparrows with
> > > cannons.  Why not extend emacs-lisp-mode to DTRT with
> > > data-that-doesn't-make-sense-as-code instead?
> > That is _exactly_ what Clément proposed in his original patch.
> My understanding is that Clément proposed a new major mode.

Yes, he did.  By "extension" (to a major mode) I understood
"derivation", as in basic OO's "Dog extends Mammal extends Animal", so a
new major mode.  Now I see you didn't mean that.

If you mean just putting if-guards in emacs-lisp-mode, then I would't
call it an "extension", really.  But never mind nomenclature, the point
is that, it (1) doesn't avoid Clément's need to put the very same
if-guards in his Flycheck code, (2) isn't reusable to work for other
file types (3) just doesn't work for other stuff that people put in
emacs-lisp-mode-hook, for which we have no possible way to if-guard
against.  It is an anti-pattern, precisely the one that simple
inheritance is designed to avoid.

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 19 Oct 2019 14:36:21 +0100
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> On Sat, Oct 19, 2019 at 12:56 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I thought it was just a guess, and I wanted us to be sure.  Are we
> > sure the problem is triggered by an attempt to invoke the byte
> > compiler on the file?
> 
> It was a guess because another Flymake backend, such as checkdoc, could
> have been producing similar bogus data.  I also didn't try Flycheck.
> Anyway the guess is confirmed for Flymake, though apparently for
> Flycheck the problem also extends to its checkdoc checker.

OK, thanks.  In that case, my proposed fix is below.

> > > > Creating a major mode for this issue is like shooting sparrows with
> > > > cannons.  Why not extend emacs-lisp-mode to DTRT with
> > > > data-that-doesn't-make-sense-as-code instead?
> > > That is _exactly_ what Clément proposed in his original patch.
> > My understanding is that Clément proposed a new major mode.
> 
> Yes, he did.  By "extension" (to a major mode) I understood
> "derivation", as in basic OO's "Dog extends Mammal extends Animal", so a
> new major mode.  Now I see you didn't mean that.

Indeed, "extend" is ambiguous in this context, sorry about not being
more clear.

> If you mean just putting if-guards in emacs-lisp-mode, then I would't
> call it an "extension", really.

No, I wouldn't call it "extension", either.  I meant to teach
elisp-mode to recognize files that have only ELisp data structures in
them, and adapting itself to such files.  I think the distinction is
mostly on the syntax level, so I'd expect it to be detected on that
level.  Since use of such files is inherent in customizing Emacs, it
would IMO make sense to have elisp-mode support them.

> But never mind nomenclature, the point
> is that, it (1) doesn't avoid Clément's need to put the very same
> if-guards in his Flycheck code, (2) isn't reusable to work for other
> file types (3) just doesn't work for other stuff that people put in
> emacs-lisp-mode-hook, for which we have no possible way to if-guard
> against.  It is an anti-pattern, precisely the one that simple
> inheritance is designed to avoid.

I agree that this is not a complete solution, but I don't think we
have a good understanding of the more general problem at this time,
and producing a major mode that needs to be manually turned on in any
file but .dir-locals.el doesn't sound like a great idea to me,
especially as I'd like elisp-mode to support such files as a built-in
feature.  The latter would be in-line with our other major modes,
which in most cases turn themselves on automatically, given some
tell-tale indications in the file's contents or its name.

Here's the patch I propose to fix this problem for Flymake:

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 516e4f9..3e4a4c0 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -256,8 +256,20 @@ emacs-lisp-mode
   (setq-local project-vc-external-roots-function #'elisp-load-path-roots)
   (add-hook 'completion-at-point-functions
             #'elisp-completion-at-point nil 'local)
-  (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
-  (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile nil t))
+  ;; .dir-locals.el fileswill cause the byte-compiler and checkdoc
+  ;; emit spurious warnings, because they don't follow the conventions
+  ;; of Emacs Lisp sources.  Until we have a better fix, like teach
+  ;; elisp-mode about files that only hold data strucvtures, we
+  ;; disable the ELisp Flymake backend for these files.
+  (unless
+      (let* ((bfname (buffer-file-name))
+             (fname (and (stringp bfname) (file-name-nondirectory bfname))))
+        (or (not (stringp fname))
+            (string-match "\\`\\.#" fname)
+            (string-equal dir-locals-file fname)))
+    (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
+    (add-hook 'flymake-diagnostic-functions
+              #'elisp-flymake-byte-compile nil t)))
 
 ;; Font-locking support.
 

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Sat, Oct 19, 2019 at 3:03 PM Eli Zaretskii <eliz@gnu.org> wrote:
> No, I wouldn't call it "extension", either.  I meant to teach
> elisp-mode to recognize files that have only ELisp data structures in
> them, and adapting itself to such files.

The "recognizing" part of that is close to impossible, in the general case.
The file can be ill-formed, for example.  And think of the false
positives.  Most of this mail is valid elisp syntax, for example (though
obviously not a elisp program).

> The latter [the major mode] would be in-line with our other major
> modes, which in most cases turn themselves on automatically, given
> some tell-tale indications in the file's contents or its name.

But we always do it on a "best-effort" basis.  Users, organization etc,
then use auto-mode-list, mode cokkies, dir-locals or even
magic-mode-alist to plug those holes.

Just because we introduce a major mode, we're not obliged to be
super-smart and turn in on whenever possible.

Of course we can study your super-recognizer-heuristic later on, but
that's a completely orthogonal problem: to follow your
bellic-ornithological metaphor, it's akin to unleashing full-scale war
on those poor sparrows.  Even if you decimate them, some will survive,
and you'll have killed many other birds in the process.  For now, just
give everyone a slingshot and be done with it.

João

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

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-19 05:52, Eli Zaretskii wrote:
> Clément, you've reported the original problem, so could you please
> tell more details about it?  What triggers the problem, and how does
> it manifest itself to the user?  Is it just due to an attempt to
> byte-compile .dir-locals.el, or is it due to something else Flymake
> does?  Thanks.

Hi Eli,

Yes, I can describe in more details.    In fact, I was first made aware of the problem while working on Flycheck, and noticed that it appeared in Flymake too.

Over the years, we've had multiple user complaints that opening .dir-locals.el files in Flycheck cause spurious warnings to appear (e.g. https://github.com/flycheck/flycheck/issues/908).  This is because Flycheck, like Flymake, tries to byte-compile these files, and runs checkdoc on them.  Both of these return spurious warnings.

Flycheck tries to run the byte-compiler and checkdoc because of the major-mode in which .dir-locals.el files are opened.  The reasoning is that, if these files are Emacs Lisp files, then they should conform to Emacs Lisp coding conventions: they should include proper headers, licenses, a `provide' form at the end, etc.  This is how Flycheck works in general: each checker is enabled by one or multiple major modes.  Flymake works in a slightly different fashion: major modes add local hooks to run the relevant checkers.

Of course, .dir-locals.el are not proper Emacs Lisp files, and as a result both the byte compiler and checkdoc produce spurious warnings — but Flycheck doesn't know that, since it relies on the current major mode to decide which checkers to run.

One workaround is to change Flycheck to pattern match on the name of the current file in addition to its major mode, so that .dir-locals.el files are not checked.  This is the solution that I will apply if we decide against introducing a separate mode for dir-locals.el.  On the Flymake side, the definition of emacs-lisp-mode would check the name of the current file, and only add the relevant Flymake hooks if the current file isn't called .dir-locals.el.

My motivation for proposing a separate mode was that we already have a mechanism (atuo-mode-alist) to attach specific behaviors to specific file names, so it seemed natural to reuse that mechanism to run different code for regular ELisp files and dir-locals files.  IOW, I thought it was an anti-pattern to do file-name checks in a major-mode definition.  

Finally, what motivated me to propose a split was the fact that a fix was needed in two places (Flymake and Flycheck), and likely in others (company and completion-at-point-functions should ideally work differently in .dir-locals.el; imenu doesn't make much sense there, ELisp syntax-highlighting is sub-optimal for these files outside of `eval' forms, etc.).

Thanks for your patience and your dedication,
Clément.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 19 Oct 2019 08:53:23 -0400
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Yes, I can describe in more details. [...]

Thanks, Clément, for your detailed description.  It really makes the
situation with Flymake crystal clear.

> My motivation for proposing a separate mode was that we already have a mechanism (atuo-mode-alist) to attach specific behaviors to specific file names, so it seemed natural to reuse that mechanism to run different code for regular ELisp files and dir-locals files.  IOW, I thought it was an anti-pattern to do file-name checks in a major-mode definition.  

But this part only works for .dir-locals.el files, it will not work
for any file named otherwise.  E.g., my saveplace file is called
_places.sav (for boring historical reasons), and the only way of using
such a new mode for it would be to manually turn it on when that file
is visited.  The same will happen with ~/.emacs.d/bookmarks and for
many other files that just hold Lisp data.

That's not how our major modes work: Emacs almost always turns them on
automatically, by examining the file's name or contents.

> Finally, what motivated me to propose a split was the fact that a fix was needed in two places (Flymake and Flycheck), and likely in others (company and completion-at-point-functions should ideally work differently in .dir-locals.el; imenu doesn't make much sense there, ELisp syntax-highlighting is sub-optimal for these files outside of `eval' forms, etc.).

I suggested to collect the traits common to these files, and then
discuss what would be the appropriate mode for them.  I don't think we
have now a clear picture of what is or might be needed.  In
particular, I don't think we have enough data to decide whether
elisp-mode should support such files as a built-in feature, or there's
enough differences to justify a separate mode.  In the latter case, we
will have to devise some way of turning on that new mode automatically
in most cases.

Thanks.

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-19 10:14, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sat, 19 Oct 2019 08:53:23 -0400
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> Yes, I can describe in more details. [...]
> 
> Thanks, Clément, for your detailed description.  It really makes the
> situation with Flymake crystal clear.

:)

>> My motivation for proposing a separate mode was that we already have a mechanism (atuo-mode-alist) to attach specific behaviors to specific file names, so it seemed natural to reuse that mechanism to run different code for regular ELisp files and dir-locals files.  IOW, I thought it was an anti-pattern to do file-name checks in a major-mode definition.  
> 
> But this part only works for .dir-locals.el files, it will not work
> for any file named otherwise. 

That's true.  I didn't give these files much thought, because (since they don't end in .el) they don't trigger emacs-lisp-mode, and so they are not a problem for Flycheck.

> E.g., my saveplace file is called
> _places.sav (for boring historical reasons), and the only way of using
> such a new mode for it would be to manually turn it on when that file
> is visited.
That's true if we were to introduce a general mode for Lisp data (and, indeed I haven't given such a mode much thought).  If we introduced a mode specifically designed for dir-locals files, on the other hand, it would be turned on automatically for all relevant files (but I see why it's more attractive to look for a solution more general than a dir-locals mode).

> I suggested to collect the traits common to these files, and then
> discuss what would be the appropriate mode for them.  I don't think we
> have now a clear picture of what is or might be needed.  In
> particular, I don't think we have enough data to decide whether
> elisp-mode should support such files as a built-in feature, or there's
> enough differences to justify a separate mode.  In the latter case, we
> will have to devise some way of turning on that new mode automatically
> in most cases.

Understood.  So, for now at least, I will push a patch to Flycheck along the lines of the patch you suggested for Flymake.

Clément.

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 19.10.2019 17:14, Eli Zaretskii wrote:
> In the latter case, we
> will have to devise some way of turning on that new mode automatically
> in most cases.

I don't think that should be a prerequisite.

But even if we wanted that, do we have a lot of other similar files that 
are created by the user, as opposed to being auto-generated? In the 
latter case we can add a 'mode: elisp-data-mode' to the file while it's 
generated with little effort.

Re: Add a separate mode for .dir-locals.el

[Alan Mackenzie]

Hello, Dmitry.

On Sat, Oct 19, 2019 at 23:41:19 +0300, Dmitry Gutov wrote:
> On 19.10.2019 17:14, Eli Zaretskii wrote:
> > In the latter case, we will have to devise some way of turning on
> > that new mode automatically in most cases.

> I don't think that should be a prerequisite.

> But even if we wanted that, do we have a lot of other similar files
> that are created by the user, as opposed to being auto-generated? In
> the latter case we can add a 'mode: elisp-data-mode' to the file while
> it's generated with little effort.

Just as little effort is "elisp-data-only: t" in the local variables
section.  This unambiguously does not contort the notion of major mode.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 20.10.2019 0:35, Alan Mackenzie wrote:
> Just as little effort is "elisp-data-only: t" in the local variables
> section.  This unambiguously does not contort the notion of major mode.

We can't be sure that it's in all .dir-locals.el.

And that doesn't save us from a conditional in each and every hook 
function that implement a facility for Emacs Lisp code.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 19 Oct 2019 23:41:19 +0300
> 
> On 19.10.2019 17:14, Eli Zaretskii wrote:
> > In the latter case, we
> > will have to devise some way of turning on that new mode automatically
> > in most cases.
> 
> I don't think that should be a prerequisite.

Why not?  It would be very unusual and inconvenient for a major mode
to require that it be manually turned on to be useful.  Do we have any
other major mode that needs that?

> But even if we wanted that, do we have a lot of other similar files that 
> are created by the user, as opposed to being auto-generated? In the 
> latter case we can add a 'mode: elisp-data-mode' to the file while it's 
> generated with little effort.

If we can automatically generate the mode cookie, we can automatically
generate any other file-local variable we might need, like
'no-byte-compile: t' or the setting for an Xref backend.

I also am not sure that all the features that read these files will be
able to DTRT with (either ignore or act upon) file-locals or cookies.
At least some of them will probably have to be modified to be able to
do that.

That's why I said this issue needs to be investigated and the
conclusions posted and discussed, before we can design a coherent
feature to support such files.  Doing that in a hurry, based on a
single incident and only on some vague ideas what other aspects of
these files may need handling, doesn't sound wise to me, especially as
the rest of the issues, whatever they are, cannot be urgent, judging
by the lack of complaints.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Sun, Oct 20, 2019 at 6:45 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > will have to devise some way of turning on that new mode automatically
> > I don't think that should be a prerequisite.
> Why not?  It would be very unusual and inconvenient for a major mode
> to require that it be manually turned on to be useful. Do we have any
> other major mode that needs that?

Of course we do, and that's why we provide so many flexible ways to let
users fix it.  I don't control the file names and extensions of most of
the files I work with, but I do control my Emacs's variables.

> If we can automatically generate the mode cookie, we can automatically
> generate any other file-local variable we might need, like
> 'no-byte-compile: t' or the setting for an Xref backend.

Then you'd have a proliferation of identical buffer-local variable
blocks.  And I know a good way to refactor that ;-)

But cookie generation would only be for very tight cases, I think, if
any at all.  Because for files whole filenames and/or standard locations
we know, such as dir-locals.el, bookmarks, ido-last, recentf,
tramp-something, etc. we can just leverage the existing auto-mode-alist
and magic-mode-alist.

_And_ we can do always it incrementally, we _dont_ have to hurry or rush
to decisions for this change to start being useful.

João

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

Re: Add a separate mode for .dir-locals.el

[Juri Linkov]

> But cookie generation would only be for very tight cases, I think, if
> any at all.  Because for files whole filenames and/or standard locations
> we know, such as dir-locals.el, bookmarks, ido-last, recentf,
> tramp-something, etc. we can just leverage the existing auto-mode-alist
> and magic-mode-alist.

Why are we talking about cluttering up auto-mode-alist with odd filenames?
There files are generated, so it's easy to add to them a cookie like:

  ;; -*- mode: emacs-lisp-data -*-

Actually ~/.emacs.d/tramp already has ;; -*- emacs-lisp -*-
But no other files.  We need to add the same cookie to

~/.emacs.d/places       - Emacs Lisp data
~/.emacs.d/recentf      - Emacs Lisp data
~/.emacs.d/eudc-options - Emacs Lisp code

and to all other files in ~/.emacs.d/

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Sun, Oct 20, 2019 at 5:32 PM Juri Linkov <juri@linkov.net> wrote:
>
> > But cookie generation would only be for very tight cases, I think, if
> > any at all.  Because for files whole filenames and/or standard locations
> > we know, such as dir-locals.el, bookmarks, ido-last, recentf,
> > tramp-something, etc. we can just leverage the existing auto-mode-alist
> > and magic-mode-alist.
> Why are we talking about cluttering up auto-mode-alist with odd filenames?
> There files are generated, so it's easy to add to them a cookie like:

To me the obvious answer would be that if we ever develop a
specialized recentf-mode, places-mode, etc... derived from
emacs-lisp-data-mode, we get to apply these modes to existing files
without having to painfully find-and-replace said cookies.

I've just never considered auto-mode-alist to be a clean place
anyway, there's lots of stuff there I've never heard of.

But the cookies aren't horrible, either.  We mainly just need
the intermediate lisp-as-data mode for now.

João

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

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 20.10.2019 8:45, Eli Zaretskii wrote:
> Why not?  It would be very unusual and inconvenient for a major mode
> to require that it be manually turned on to be useful.

Like I explained, it wouldn't have to be turned on manually. In any 
case, the subset of such files that people routinely edit manually isn't 
big.

> That's why I said this issue needs to be investigated and the
> conclusions posted and discussed, before we can design a coherent
> feature to support such files.  Doing that in a hurry, based on a
> single incident and only on some vague ideas what other aspects of
> these files may need handling, doesn't sound wise to me, especially as
> the rest of the issues, whatever they are, cannot be urgent, judging
> by the lack of complaints.

It is indeed not urgent. I think it's an argument to postpone the 
proposed change (new major mode and stuff) until after Emacs 27. But not 
against doing it in general.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Oct 2019 15:43:09 +0300
> Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> > That's why I said this issue needs to be investigated and the
> > conclusions posted and discussed, before we can design a coherent
> > feature to support such files.  Doing that in a hurry, based on a
> > single incident and only on some vague ideas what other aspects of
> > these files may need handling, doesn't sound wise to me, especially as
> > the rest of the issues, whatever they are, cannot be urgent, judging
> > by the lack of complaints.
> 
> It is indeed not urgent. I think it's an argument to postpone the 
> proposed change (new major mode and stuff) until after Emacs 27. But not 
> against doing it in general.

It depends on what will be conclusions of the investigation.  Maybe it
will find some good reasons to do this even in Emacs 27, although I'd
be surprised.  But my point about the "hurry" was not about
postponing, it was that we shouldn't make the decision before we have
a good understanding of the problem beyond the specific issue with
.dir-locals.el

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 21.10.2019 16:15, Eli Zaretskii wrote:
> it was that we shouldn't make the decision before we have
> a good understanding of the problem beyond the specific issue with
> .dir-locals.el

I think we do, they are just spread evenly across this discussion.

1. Flycheck will have to duplicate the same filename check. And IDK if 
the same problem applies to other similar files mentioned in this 
discussion. I can't find the beginning of this discussion. The current 
thread starts with Lars's "Makes sense to me" in my email client.

2. elisp-completion-at-point will need to add the same check and do 
something different to give better results when such file is being 
edited. E.g. currently where the user types a variable name is suggests 
functions only (in .dir-locals.el).

3. (add-hook 'after-load-functions 
#'elisp--font-lock-flush-elisp-buffers) seems strictly unnecessary in 
such files.

4. project-vc-external-roots-function should probably be nil, but it's 
not really hurting anyone.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019 at 2:34 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 21.10.2019 16:15, Eli Zaretskii wrote:
> > it was that we shouldn't make the decision before we have
> > a good understanding of the problem beyond the specific issue with
> > .dir-locals.el
>
> I think we do, they are just spread evenly across this discussion.
>
> 1. Flycheck will have to duplicate the same filename check. And IDK if
> the same problem applies to other similar files mentioned in this
> discussion. I can't find the beginning of this discussion. The current
> thread starts with Lars's "Makes sense to me" in my email client.
>
> 2. elisp-completion-at-point will need to add the same check and do
> something different to give better results when such file is being
> edited. E.g. currently where the user types a variable name is suggests
> functions only (in .dir-locals.el).
>
> 3. (add-hook 'after-load-functions
> #'elisp--font-lock-flush-elisp-buffers) seems strictly unnecessary in
> such files.
>
> 4. project-vc-external-roots-function should probably be nil, but it's
> not really hurting anyone.
>

Add `which-function-mode` to the list, please, also produces
bogus results.

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Oct 2019 16:34:02 +0300
> 
> On 21.10.2019 16:15, Eli Zaretskii wrote:
> > it was that we shouldn't make the decision before we have
> > a good understanding of the problem beyond the specific issue with
> > .dir-locals.el
> 
> I think we do, they are just spread evenly across this discussion.

What you list is part of the issue, but it isn't all of it.  Many
additional data files were mentioned, but not in detail.  I think we
should have a better idea about which ones are relevant to this and
what would be a reasonable way of handling them.

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 19.10.2019 15:53, Clément Pit-Claudel wrote:
> Finally, what motivated me to propose a split was the fact that a fix was needed in two places (Flymake and Flycheck), and likely in others (company and completion-at-point-functions should ideally work differently in .dir-locals.el; imenu doesn't make much sense there, ELisp syntax-highlighting is sub-optimal for these files outside of `eval' forms, etc.).

Exactly.

xref-backend-functions and project-external-roots-functions come to mind 
as well. And they all will have to duplicate the check.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 19 Oct 2019 23:38:20 +0300
> 
> On 19.10.2019 15:53, Clément Pit-Claudel wrote:
> > Finally, what motivated me to propose a split was the fact that a fix was needed in two places (Flymake and Flycheck), and likely in others (company and completion-at-point-functions should ideally work differently in .dir-locals.el; imenu doesn't make much sense there, ELisp syntax-highlighting is sub-optimal for these files outside of `eval' forms, etc.).
> 
> Exactly.
> 
> xref-backend-functions and project-external-roots-functions come to mind 
> as well. And they all will have to duplicate the check.

What check did you have in mind?  AFAIK, the hooks you mention don't
need to byte-compile the file, so the issue at hand is not relevant
for them.  And at least for Xref, I don't see why it should handle
ELisp data files differently from any other ELisp files.

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 20.10.2019 8:38, Eli Zaretskii wrote:

>> xref-backend-functions and project-external-roots-functions come to mind
>> as well. And they all will have to duplicate the check.
> 
> What check did you have in mind? 

The "does this file contain an Elisp program" check.

> AFAIK, the hooks you mention don't
> need to byte-compile the file, so the issue at hand is not relevant
> for them.  And at least for Xref, I don't see why it should handle
> ELisp data files differently from any other ELisp files.

That depends on how we want to treat those files in general. If each 
such file is an "opaque" Lisp form, there's no reason to expect even 
normal Elisp variables here. So Xref could simply show/do nothing.

But okay, we can assume that such files will contain symbols 
corresponding to variables/functions/etc in the current Emacs session. 
Seeing feature names there is highly unlikely, though, so Xref could 
filter out those in the search results. *If* the current file is in 
elisp-data-mode.

project-external-roots-functions, again, would probably return nil in 
such files.

And elisp-completion-at-point, as people mentioned already, would have 
to special-case them as well. So we might as well write a new completion 
function, for a new major mode.

So we have several features that, somewhere in the implementation, will 
need to make that check and act differently because of that. A new major 
mode will do that nicely.

Speaking of no-brainers, I don't see why you're fighting this one.

Major modes are one of our methods of extensibility. Someone somewhere 
will create a new package/file-name/use-case for such files. They'll 
only have to add a new entry to auto-mode-alist, and voila, the new 
Elisp Data file buffer behaves as expected. They won't have to wait 
until Emacs hardcodes the new file name somewhere as well.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 20 Oct 2019 23:21:11 +0300
> 
> So we have several features that, somewhere in the implementation, will 
> need to make that check and act differently because of that. A new major 
> mode will do that nicely.

And the current major mode mostly does TRT already, as you yourself
point out.

> Speaking of no-brainers, I don't see why you're fighting this one.

I don't like the idea, given the motivation.  Am I allowed to have gut
feelings?  Is the question "why you're fighting this one" only
applicable to me?

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019, 07:24 Eli Zaretskii <eliz@gnu.org> wrote:

>
> > Speaking of no-brainers, I don't see why you're fighting this one.
>
> I don't like the idea, given the motivation.  Am I allowed to have gut
> feelings?  Is the question "why you're fighting this one" only
> applicable to me?
>

Perhaps your gut feeling is that we're trying to stuff a feature request
behind a reasonably silly bug report.  If it is, you're right! But it's a
really nice feature, cheap and useful, and lots to offer to users and
package authors. (Oh and solves the bug).

João

>

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 21 Oct 2019 08:05:09 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
>  I don't like the idea, given the motivation.  Am I allowed to have gut
>  feelings?  Is the question "why you're fighting this one" only
>  applicable to me?
> 
> Perhaps your gut feeling is that we're trying to stuff a feature request behind a reasonably silly bug report.  If it
> is, you're right! But it's a really nice feature, cheap and useful, and lots to offer to users and package authors.

I don't agree that it's a nice feature.  I don't even understand why
we give up so easily on elisp-mode support for such "data files",
something that should be quite natural, and instead want some
"inferior" mode based on file names and manual turning on of the mode.
It simply feels wrong, as file names have nothing to do with the
actual issue of doing TRT with Lisp data.

But this all was already said many times, we just keep going in
circles with no new arguments anywhere in sight.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019 at 8:15 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I don't agree that it's a nice feature.  I don't even understand why
> we give up so easily on elisp-mode support for such "data files",
>

Because elisp-mode is for emacs-lisp programs,
not lisp data. Can you concede that, or is that still controversial?

If we want to make it work for lisp data like you propose we
have to conditionally remove things from it.  Which is possible,
but ugly, and downright impossible when those things come
from emacs-lisp-mode-hook.

And, in your patch, we would be tying it to a file name, which
is needlessly hacky.

It's much better to recognize the part of emacs-lisp-mode that is
_common_ to data (and there is a lot) and extract that into a
new function.  That that function is called "a major mode" is just
a name, it's nor a "major thing" at all, it's just 5-6 lines and
a 1kB table.

something that should be quite natural, and instead want some
> "inferior" mode based on file names and manual turning on of the mode.
> It simply feels wrong, as file names have nothing to do with the
> actual issue of doing TRT with Lisp data.
>
> But this all was already said many times, we just keep going in
> circles with no new arguments anywhere in sight.
>

I've (and we've) summarized the arguments, given "arguments
from the future" and replied to your own "arguments from the
future".

But it is, by definition, impossible to argue with "gut feeling"
and "feels wrong" or "should be natural". I just don't know
how to talk to your gut (or even if I want to).

It's because I want to believe that Emacs is a rational place,
that I ask to rebut the concrete evidence that is being
presented here, or yield to it.

If it helps, I concede that file names are indeed an
orthogonal problem.  They are simply one of the best heuristics
we have to guess the file content. Take filenames out of the
equation, please. We can discuss a better heuristic later, say
a machine learning one (it's all the rage nowadays).  For now,
just focus on the pros and cons of making a major mode for
lisp data.

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 21 Oct 2019 09:25:00 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
>  I don't agree that it's a nice feature.  I don't even understand why
>  we give up so easily on elisp-mode support for such "data files",
> 
> Because elisp-mode is for emacs-lisp programs, 
> not lisp data. Can you concede that, or is that still controversial?

No, I disagree.  Lisp data is as much Lisp as Lisp programs.  There's
no distinction in Lisp between data and code.

This was also already said several times.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019 at 11:10 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> > not lisp data. Can you concede that, or is that still controversial?
> No, I disagree.  Lisp data is as much Lisp as Lisp programs.  There's
> no distinction in Lisp between data and code.
>

A lisp program file is a Lisp data file, we concur.
A lisp data is _not necessarily_ a lisp program file.

I.e. we have:

    lisp program     ==>    lisp data

but _not_:

    lisp program    <===> lisp data

Here is another way to look at it: If this last proposition were true,
we would have no problem, nothing to fix. Yet, we do. You have
even provided a patch. Hence, your proposition conflicts with
reality, i.e. is false.


> This was also already said several times.
>

By you, exclusively, right?  Or by someone else I missed?

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 21 Oct 2019 11:28:01 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
>  > not lisp data. Can you concede that, or is that still controversial?
>  No, I disagree.  Lisp data is as much Lisp as Lisp programs.  There's
>  no distinction in Lisp between data and code.
> 
> A lisp program file is a Lisp data file, we concur.
> A lisp data is _not necessarily_ a lisp program file.

There is no "Lisp program", only "Lisp data".  A program is Lisp data
that makes sense as a program.

> Here is another way to look at it: If this last proposition were true, 
> we would have no problem, nothing to fix. Yet, we do. You have
> even provided a patch. Hence, your proposition conflicts with 
> reality, i.e. is false.

The argument is not about the need for a fix, it's about where the fix
should be.  Ideally, the byte-compiler should have got its act
together and not attempted to produce code out of those files.
Failing that, we need to help the byte compiler DTRT.

>  This was also already said several times.
> 
> By you, exclusively, right?  Or by someone else I missed?

Also by Andreas and by Richard.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019 at 11:59 AM Eli Zaretskii <eliz@gnu.org> wrote:
> There is no "Lisp program", only "Lisp data".  A program is Lisp data
> that makes sense as a program.

Yes, and your last sentence describes exactly what I like to
call a "Lisp program". Let's just agree to give it that name,
OK. So that it "exists" (in fact a large part of Emacs is made
up of the stuff).

> The argument is not about the need for a fix, it's about where the fix
> should be.  Ideally, the byte-compiler should have got its act
> together and not attempted to produce code out of those files.
> Failing that, we need to help the byte compiler DTRT.

It's been shown many times the problem is not exclusive to the
byte-compiler. It's merely an example of a tool that only makes
exclusive sense for "Lisp programs", or "data that makes sense
as a program" as you put it.

> >  This was also already said several times.
> > By you, exclusively, right?  Or by someone else I missed?
> Also by Andreas and by Richard.
Not true of Richard: he said "All code is data, but only some
data is code". That is exactly the distinction I am making.

João

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

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 21 Oct 2019 12:22:38 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> > >  This was also already said several times.
> > > By you, exclusively, right?  Or by someone else I missed?
> > Also by Andreas and by Richard.
> Not true of Richard: he said "All code is data, but only some 
> data is code". That is exactly the distinction I am making.

No, it isn't.

Anyway, let's agree to disagree on this, okay?  This is a minor issue,
and we've already invested too much energy in discussing it.  I don't
see how continuing this will help anything.

Thanks.

Re: Add a separate mode for .dir-locals.el

[João Távora]

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

On Mon, Oct 21, 2019 at 12:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > > >  This was also already said several times.
> > > > By you, exclusively, right?  Or by someone else I missed?
> > > Also by Andreas and by Richard.
> > Not true of Richard: he said "All code is data, but only some
> > data is code". That is exactly the distinction I am making.
> No, it isn't.
>

If you so decree it, then indeed I have nothing to add.

João

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

Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 21.10.2019 9:24, Eli Zaretskii wrote:

>> So we have several features that, somewhere in the implementation, will
>> need to make that check and act differently because of that. A new major
>> mode will do that nicely.
> 
> And the current major mode mostly does TRT already, as you yourself
> point out.

There's no *and* here. I'm talking about how the current major mode will 
have to function.

It does TRT only for Xref, but not for completion-at-point-functions, or 
Flymake/Flycheck. As I have pointed out in some detail.

>> Speaking of no-brainers, I don't see why you're fighting this one.
> 
> I don't like the idea, given the motivation.  Am I allowed to have gut
> feelings?

I suppose. Though, when asked, in similar situations I try to describe 
my "gut feeling" in logical terms, in terms of user experience, etc. 
Similarly to what I have done in this discussion.

When one side wields explanations and another is based on gut feeling, 
is often when we have long, pointless discussions like this one.

> Is the question "why you're fighting this one" only
> applicable to me?

I don't think so. In general, we should use it more often.

For instance, in the very discussion where I got the "no-brainer" quote 
from, I conceded the essence of the change and now only focus on the 
details of the implementation.

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> "Gross" means that it solves the problem not where it is caused, and

FWIW, I disagree on this judgment: it's not the only acceptable place to
solve this problem, but I think it's pretty close to its origin.

Fixing it in fly*.el would be "gross" as would become evident if you
tried to write a patch for it.  If you want the patch to be specific to
flymake it'll have to go either to `elisp-mode` or to
elisp-flymake-*, all of which live in elisp-mode.el.

Of course, changing `elisp-mode` or elisp-flymake-* of course won't help
fixing the problem for flycheck (nor will it help with other things we
may want to fix such as the M-C-x binding which makes no sense in
.dir-locals.el, or the presence of "Byte-compile this file" in the
menu, ...).

I don't care if we make it a separate major mode or not, but I think
it's important to recognize that the origin of the problem is the
difference between buffers that contain Elisp code and buffers that
contain Elisp data.  I agree that at some level they are theoretically
the same, but in practice they exhibit important differences.


        Stefan

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: João Távora <joaotavora@gmail.com>,
>   cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 15:50:41 -0400
> 
> > "Gross" means that it solves the problem not where it is caused, and
> 
> FWIW, I disagree on this judgment: it's not the only acceptable place to
> solve this problem, but I think it's pretty close to its origin.

In what sense is it close?

> Fixing it in fly*.el would be "gross" as would become evident if you
> tried to write a patch for it.  If you want the patch to be specific to
> flymake it'll have to go either to `elisp-mode` or to
> elisp-flymake-*, all of which live in elisp-mode.el.

elisp-flymake-* at least have the advantage of having "flymake" in
their names, so some relation is evident.

> I agree that at some level they are theoretically the same, but in
> practice they exhibit important differences.

Differences that are important for an Emacs major mode?  What
differences are those?

And why not make emacs-lisp-mode recognize these differences and
support them accordingly?

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> elisp-flymake-* at least have the advantage of having "flymake" in
> their names, so some relation is evident.

Just because the original description of the problem talked about
flymake doesn't mean the problem is specific to flymake.

>> I agree that at some level they are theoretically the same, but in
>> practice they exhibit important differences.
> Differences that are important for an Emacs major mode?
> What differences are those?

To quote the email to which you reply:

   ... other things we may want to fix such as the M-C-x binding which
   makes no sense in .dir-locals.el, or the presence of "Byte-compile
   this file" in the menu, ...

These probably aren't that important, admittedly.  But completion in
.dir-locals.el doesn't work very well right now, because the data has
the form (VAR . VAL) but the completion function presumes this is Elisp
*code* where the head of a list should be a function rather than
a variable, so it will give you bogus completions when trying to
complete the variable names.  We couldn't cleanly fix this completion in
a generic emacs-lisp-data-mode, tho: we'd need something more specific
like a dir-locals-mode.

> And why not make emacs-lisp-mode recognize these differences and
> support them accordingly?

As I said "I don't care if we make it a separate major mode or not".

Tho I was partly lying: I do think a separate major mode is a better
choice down the line (e.g. it makes it easier to use auto-mode-alist
and -*-...-*- to specify the behavior to use for .dir-locals.el,
~/.emacs.d/bookmarks, ~/.emacs.d/tramp, ~/.emacs.d/ecomplterc, ...), but
that's a fairly minor detail compared to the fact that the issue goes
much further than "flymake in .dir-locals.el".


        Stefan

Re: Add a separate mode for .dir-locals.el

[Michael Albinus]

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

Hi,

> As I said "I don't care if we make it a separate major mode or not".
>
> Tho I was partly lying: I do think a separate major mode is a better
> choice down the line (e.g. it makes it easier to use auto-mode-alist
> and -*-...-*- to specify the behavior to use for .dir-locals.el,
> ~/.emacs.d/bookmarks, ~/.emacs.d/tramp, ~/.emacs.d/ecomplterc, ...), but
> that's a fairly minor detail compared to the fact that the issue goes
> much further than "flymake in .dir-locals.el".

For whom it's worth, I agree with Stefan to add a new major mode. *I*,
being Tramp maintainer, analyzing .../tramp files from everywhere
everyday, would profit.

But it is also true, that the mentioned files are rarely edited
interactively, except .dir-locals.el.

>         Stefan

Best regards, Michael.

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: joaotavora@gmail.com,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 16:32:59 -0400
> 
> > elisp-flymake-* at least have the advantage of having "flymake" in
> > their names, so some relation is evident.
> 
> Just because the original description of the problem talked about
> flymake doesn't mean the problem is specific to flymake.

Then maybe we should step back and describe the problem better.  I
already suggested that a few emails ago.  Until now, the only problem
that triggered this discussion was with Flymake.

> > Differences that are important for an Emacs major mode?
> > What differences are those?
> 
> To quote the email to which you reply:
> 
>    ... other things we may want to fix such as the M-C-x binding which
>    makes no sense in .dir-locals.el, or the presence of "Byte-compile
>    this file" in the menu, ...

The former might make sense, because .dir-locals.el can include 'eval'
forms, right?  If we care about the latter, it can be handled by being
sensitive to 'no-byte-compile: t' instead.  Or even compare with the
file name, as bytecomp.el already does, as do other places.

> These probably aren't that important, admittedly.

Exactly.

> But completion in .dir-locals.el doesn't work very well right now,
> because the data has the form (VAR . VAL) but the completion
> function presumes this is Elisp *code* where the head of a list
> should be a function rather than a variable, so it will give you
> bogus completions when trying to complete the variable names.  We
> couldn't cleanly fix this completion in a generic
> emacs-lisp-data-mode, tho: we'd need something more specific like a
> dir-locals-mode.
> 
> > And why not make emacs-lisp-mode recognize these differences and
> > support them accordingly?
> 
> As I said "I don't care if we make it a separate major mode or not".
> 
> Tho I was partly lying: I do think a separate major mode is a better
> choice down the line (e.g. it makes it easier to use auto-mode-alist
> and -*-...-*- to specify the behavior to use for .dir-locals.el,
> ~/.emacs.d/bookmarks, ~/.emacs.d/tramp, ~/.emacs.d/ecomplterc, ...), but
> that's a fairly minor detail compared to the fact that the issue goes
> much further than "flymake in .dir-locals.el".

This all sounds to me like "arguments from the future": we don't yet
have any substantial reasons to define a major mode, but we are trying
hard to think of any potential reason we might have in the future.

If someone wants to work on such a comprehensive elisp-data-mode, with
all the bells and whistles presented above, then by all means please
do.  When the job is done, let's look at the result and decide whether
we want this in core, in ELPA, or not at all.  But until that happens,
all we have is this one minor problem, so the only urgent part is to
solve that problem.  And I consider adding a new major mode for that
as uneconomical, inelegant, and potentially a maintenance burden (if,
as I presume, the more general mode will never materialize).

Please bear with me.  We need to start pretesting Emacs 27 as soon as
possible, and adding unnecessary new features is the wrong way of
making this happen sooner rather than later.

TIA

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

>>    ... other things we may want to fix such as the M-C-x binding which
>>    makes no sense in .dir-locals.el, or the presence of "Byte-compile
>>    this file" in the menu, ...
>
> The former might make sense, because .dir-locals.el can include 'eval'
> forms, right?

No, because those forms won't start in column 0, so C-x C-e might work,
but C-M-x won't.

> If we care about the latter, it can be handled by being
> sensitive to 'no-byte-compile: t' instead.

You really want to have to add `no-byte-compile: t` to every
.dir-locals.el instead of adding an auto-mode-alist rule?

> Or even compare with the file name, as bytecomp.el already does, as do
> other places.

Yes, we can come up with all kinds of hacks, of course.  Not sure why
you'd want to do that instead of using the clean&simple approach of
a separate major mode so you can rely on standard mechanisms like
auto-mode-alist.

> This all sounds to me like "arguments from the future": we don't yet
> have any substantial reasons to define a major mode, but we are trying
> hard to think of any potential reason we might have in the future.

I don't understand what you're getting at.  You seem to think that
creating a major mode is a big deal.  It's not.

I don't need any special reason to define a major mode.
It's not like it's a complex thing to do with far
reaching consequences.  It's a small matter of writing the following
three trivial lines of code:

    (define-derived-mode emacs-lisp-data-mode prog-mode "Emacs-Lisp-Data"
      "Major mode for buffers holding data written in Emacs Lisp syntax."
      :group 'lisp

changing

    (define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp"
    (define-derived-mode emacs-lisp-mode emacs-lisp-data-mode "Emacs-Lisp"

and moving three other lines.  This in itself makes no visible
difference to users at all, and it's very easy to see that it's the case
(the main impact is likely the allocation of about 1KB for the syntax
table).

This then lets us solve the original problem by adding a single line
to auto-mode-alist which can be trivially shown to only affect those
files that happen to match the regexp we choose to use there.

So they're all simple and safe steps.

Creating a major mode is cheap and easy.  No need to be afraid.  Even if
it inserts itself inside a pre-existing part of the hierarchy as is the
case here.


        Stefan

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 18 Oct 2019 09:11:19 -0400
> Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, emacs-devel@gnu.org
> 
> >>    ... other things we may want to fix such as the M-C-x binding which
> >>    makes no sense in .dir-locals.el, or the presence of "Byte-compile
> >>    this file" in the menu, ...
> >
> > The former might make sense, because .dir-locals.el can include 'eval'
> > forms, right?
> 
> No, because those forms won't start in column 0, so C-x C-e might work,
> but C-M-x won't.

But 'eval' forms could also include a defun, could they not?

> > If we care about the latter, it can be handled by being
> > sensitive to 'no-byte-compile: t' instead.
> 
> You really want to have to add `no-byte-compile: t` to every
> .dir-locals.el instead of adding an auto-mode-alist rule?

How is it different from adding 'mode: elisp-data' to every relevant
file?  You did say there were files whose names are not
.dir-locals.el, right?

> > Or even compare with the file name, as bytecomp.el already does, as do
> > other places.
> 
> Yes, we can come up with all kinds of hacks, of course.

You can call those "hacks", but we've been doing them for quite some
time, and evidently didn't consider them to be such bad hacks.
Suddenly one more of them makes them unbearable?

> Not sure why you'd want to do that instead of using the clean&simple
> approach of a separate major mode so you can rely on standard
> mechanisms like auto-mode-alist.

Because I don't consider it clean.

> This then lets us solve the original problem by adding a single line
> to auto-mode-alist which can be trivially shown to only affect those
> files that happen to match the regexp we choose to use there.

It isn't a single line, see above.

> Creating a major mode is cheap and easy.  No need to be afraid.  Even if
> it inserts itself inside a pre-existing part of the hierarchy as is the
> case here.

Creating a major mode for this issue is like shooting sparrows with
cannons.  Why not extend emacs-lisp-mode to DTRT with
data-that-doesn't-make-sense-as-code instead?

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

>> Creating a major mode is cheap and easy.
> Creating a major mode for this issue is like shooting sparrows with
> cannons.

Only if you have the mistaken impression that creating a major mode is
comparable to a cannon.

Anyway, I'm out of this thread.  Do it as you want: you can kick the can
an inch further and ask everybody else to do the same, or you can fix
it right once and for all.  Both options have their advantages, and
we've all made it more than clear which color we like for this bikeshed.


        Stefan

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Clément Pit-Claudel
>  <cpitclaudel@gmail.com>,  emacs-devel <emacs-devel@gnu.org>
> Date: Thu, 17 Oct 2019 11:32:24 -0400
> 
> > A better option would be to have a base `lisp-prog-mode` and hen
> > derive emacs-lisp-mode from it.
> 
> Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.

I disagree that dir-locals-mode should exist.

Re: Add a separate mode for .dir-locals.el

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 17, 2019 at 19:36:18 +0300, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  Clément Pit-Claudel
> >  <cpitclaudel@gmail.com>,  emacs-devel <emacs-devel@gnu.org>
> > Date: Thu, 17 Oct 2019 11:32:24 -0400

> > > A better option would be to have a base `lisp-prog-mode` and hen
> > > derive emacs-lisp-mode from it.

> > Exactly.  dir-locals-mode should share a parent with emacs-lisp-mode.

> I disagree that dir-locals-mode should exist.

I agree with you.

The motivation for dir-locals-mode seems to be solely that there's some
problem in fly{make,check}-mode involving .dir-locals.

What key bindings would people want in dir-locals-mode?  What indentation
strategies, what font-locking?  Nobody's given such positive reasons, as
yet (unless I've missed a post).

And making a common ancestor for this new mode and emacs-lisp-mode would
be a Bad Thing.  It would fragment e-l-m for no particular gain.

I say there should be no such new mode.  The problems should be fixed in
fly*.el, which surely should be possible.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> I say there should be no such new mode.  The problems should be fixed in
> fly*.el, which surely should be possible.

It definitely does not belong in fly*.el which should know nothing about
emacs-lisp-mode or any specific major mode for that matter.


        Stefan

Re: Add a separate mode for .dir-locals.el

[Alan Mackenzie]

Hello, Stefan.

On Thu, Oct 17, 2019 at 14:08:45 -0400, Stefan Monnier wrote:
> > I say there should be no such new mode.  The problems should be fixed in
> > fly*.el, which surely should be possible.

> It definitely does not belong in fly*.el which should know nothing about
> emacs-lisp-mode or any specific major mode for that matter.

Well, fly*.el needs to know _some_ things about its potential target
files.  For example, that they can be sensibly submitted to make.
Determining this shouldn't require emacs-lisp-mode to be fragmented.

I don't know much about these fly* modes (I don't use them), but somehow
they must contain a mechanism analogous to auto-mode-alist which
determines whether (and possibly how) to submit a file to make.  Surely
this mechanism is the place to filter out .dir-locals.el and similar
files.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

> I don't know much about these fly* modes (I don't use them), but somehow

Same modeal as imenu, font-lock, comment-dwim, outline-minor-mode, younameit.

> they must contain a mechanism analogous to auto-mode-alist which

Nope.


        Stefan

Re: Add a separate mode for .dir-locals.el

[João Távora]

Alan Mackenzie <acm@muc.de> writes:

> What key bindings would people want in dir-locals-mode?  What indentation
> strategies, what font-locking?

The answer to these questions lies in these lines of Stefan's patch,
which is extremely easy to read:

+(define-derived-mode emacs-lisp-data-mode prog-mode "Emacs-Lisp-Data"
+  "Major mode for buffers holding data written in Emacs Lisp syntax."
+  :group 'lisp
+  (lisp-mode-variables nil nil 'elisp)
+  (setq-local electric-quote-string t)
+  (setq imenu-case-fold-search nil))

> Nobody's given such positive reasons, as yet (unless I've missed a
> post).

I think you've missed at least a couple (aside from the original one)

> And making a common ancestor for this new mode and emacs-lisp-mode would
> be a Bad Thing.  It would fragment e-l-m for no particular gain.

What exactly do you mean by "fragmentation"?  What is the thing that you
can do now that you believe you will not be able to do later?

João

Re: Add a separate mode for .dir-locals.el

[Alan Mackenzie]

Hello, João.

On Thu, Oct 17, 2019 at 19:19:39 +0100, João Távora wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > And making a common ancestor for this new mode and emacs-lisp-mode
> > would be a Bad Thing.  It would fragment e-l-m for no particular
> > gain.

> What exactly do you mean by "fragmentation"?

Something which is a coherent whole and is currently in one place will
be split amongst two, or several, places, leaving it less coherent.

> What is the thing that you can do now that you believe you will not be
> able to do later?

Nothing, of course.  But it will be more difficult, less pleasant, more
frustrating and more error-prone.  Maybe not by a lot, but noticeably
so.

There were several bugs several years ago caused by the introduction of
prog-mode.  And there are now features in major modes where it's not
obvious whether they're implemented in prog-mode or the major mode
itself.  Finding that out is extra work.  That's fragmentation.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add a separate mode for .dir-locals.el

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 17 Oct 2019 14:59:34 +0100
> 
> > Why is that a hack?  Shouldn't Flymake "understand" the file it is
> > working on, including its syntax etc.?
>  
> In fact, no.  Not the new Flymake at least (and even in the old one I
> have my doubts).  That is a job for mode-specific functions that hook
> onto Flymake's interfaces.  They are known as Flymake backends and
> usually place themselves in the local value of the
> flymake-diagnostic-functions hook.  For lisp/elisp-mode.el, there are
> two backends: elisp-flymake-byte-compile and elisp-flymake-checkdoc.
> 
> Maybe I misunderstood your suggestion: if you meant changing _those_ two
> backends so that they notice they are in a dir-locals file and disable
> themselves, then it's less bad.

That could be an okay solution, I think.

> But I you'd probably be adding more
> complexity to progmodes/elisp-mode.el than you would (to the same file,
> I guess) by setting up a trivial derived dir-locals-mode.

OTOH, having a major mode just to pacify some minor mode sounds gross
to me.  Especially, and here I agree with Andreas, as there's nothing
special in .dir-locals.el except that it always includes mostly data
(and even that is inaccurate, since it can call eval).

> BTW, and on a tangent, a derived dir-locals-mode isn't the
> bestoption. In OO, a derivation that _removes_functionality is a
> no-no,it breaks "is a".

So we agree on that.

Re: Add a separate mode for .dir-locals.el

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> That could be an okay solution, I think.

It's not ideal, but it's as easy as signalling a condition (maybe an
error) in the backend.  Flymake already interprets that a message from
the backend saying "I can't do anything here", and adds it to its
internal log.

>> But I you'd probably be adding more
> (and even that is inaccurate, since it can call eval).

The byte-compiler, and hence the elisp-flymake-byte-compile backend
would be mostly blind to that, too.

>> BTW, and on a tangent, a derived dir-locals-mode isn't the
>> bestoption. In OO, a derivation that _removes_functionality is a
>> no-no,it breaks "is a".
> So we agree on that.

I'm glad we do, too.  But we wouldn't be burning many bridges if we
break that for now, i.e. when we eventually decide to reorganize the
inheritance, we could keep the using the dir-locals-mode name.

João

PS: Again, on a tangent, and agreeing with Stefan that a dir-locals-mode
would probably be of more use than just for Flymake, other
"intermediate" modes that mixin some of elisp-mode's functionality would
be very welcome.  My top priority would be to have xref-find-definitions
(M-.)  work in *Help* for elisp functions.

Re: Add a separate mode for .dir-locals.el

[Andreas Schwab]

On Okt 16 2019, Clément Pit-Claudel <cpitcla@mit.edu> wrote:

> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
> not proper Emacs Lisp files;

In which way are they not proper?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 04:55, Andreas Schwab wrote:
> On Okt 16 2019, Clément Pit-Claudel <cpitcla@mit.edu> wrote:
> 
>> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
>> not proper Emacs Lisp files;
> 
> In which way are they not proper?

They are data, not code: for example, this .dir-locals.el:

  ;;; Directory Local Variables
  ;;; For more information see (info "(emacs) Directory Variables")

  ((latex-mode . ((TeX-engine . default))))

Re: Add a separate mode for .dir-locals.el

[Andreas Schwab]

On Okt 17 2019, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:

> On 2019-10-17 04:55, Andreas Schwab wrote:
>> On Okt 16 2019, Clément Pit-Claudel <cpitcla@mit.edu> wrote:
>> 
>>> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
>>> not proper Emacs Lisp files;
>> 
>> In which way are they not proper?
>
> They are data, not code: for example, this .dir-locals.el:

In Lisp, code is data and data is code.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-17 08:03, Andreas Schwab wrote:
> On Okt 17 2019, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
>> On 2019-10-17 04:55, Andreas Schwab wrote:
>>> On Okt 16 2019, Clément Pit-Claudel <cpitcla@mit.edu> wrote:
>>>
>>>> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
>>>> not proper Emacs Lisp files;
>>>
>>> In which way are they not proper?
>>
>> They are data, not code: for example, this .dir-locals.el:
> 
> In Lisp, code is data and data is code.

Code is data and data is sometimes code, sometimes malformed code, sometimes not code at all. Like in that example that I posted, where Emacs is kind enough to point out that "‘(latex-mode (TeX-engine . default))’ is a malformed function".  Eval'ing yields about the same message: "(invalid-function (latex-mode (TeX-engine . default)))"

Re: Add a separate mode for .dir-locals.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In Lisp, code is data and data is code.

All code is data, but only some data is code.
For instance, the list (1 2 3) is meaningless as code.

To ask whether certain data is meant to be evaluated as an expression
is a significant question.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Add a separate mode for .dir-locals.el

[Stefan Monnier]

>> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
>> not proper Emacs Lisp files;
> In which way are they not proper?

They use the Sexp syntax of Elisp, but other than that, they're not
Elisp in the sense that they don't contain Elisp expressions.

I think it makes a lot of sense to make them use a different major-mode.
Not just for flymake.  They could also use different font-lock rules,
they could benefit fromad-hoc key-bindings to add/remove settings, ...


        Stefan

Why we SHOULDN'T add a separate mode for .dir-locals.el

[Alan Mackenzie]

Hello, Stefan.

On Thu, Oct 17, 2019 at 09:40:32 -0400, Stefan Monnier wrote:
> >> .dir-locals.el files are currently opened in emacs-lisp-mode, but they are
> >> not proper Emacs Lisp files;
> > In which way are they not proper?

> They use the Sexp syntax of Elisp, but other than that, they're not
> Elisp in the sense that they don't contain Elisp expressions.

So what?  There's nothing against one major mode being appropriate for
several "types" of file, for whatever meaning of type.

> I think it makes a lot of sense to make them use a different major-mode.

I disagree entirely.  The talk has been about cutting things out of
Emacs Lisp Mode to make a new mode.  So, the question arises, what
should be cut out?

Answer; NOTHING!  I want all the facilities of Emacs Lisp Mode whilst
editing a .dir-locals.el, not to have some overlord determine for me
what I don't really want.

> Not just for flymake.  They could also use different font-lock rules,
> they could benefit fromad-hoc key-bindings to add/remove settings, ...

I think you're just making hypothetical arguments for a new mode, here.
What specifically is wrong with Emacs Lisp Mode's font locking for
.dir-locals.el?

As for the add-hoc key bindings, the normal way to do that is with a
minor mode, surely?  What particular settings were you thinking about,
anyway?

#########################################################################

So, the situation we find ourselves in is that we want all of Emacs Lisp
Mode to be operational whilst editing .dir-locals.el.  We don't really
want anything extra (or if we do, a minor mode is the way to do it).

This is the prime criterion for having a single major mode for
.dir-locals.el and foo.el.

#########################################################################

It seems there's some sort of a problem (which I don't fully understand)
in the relationship between Emacs Lisp Mode, dir-locals.el and
flymake.el.  Since a separate major mode for dir-locals.el isn't
sensible, some other appropriate way of solving that problem.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why we SHOULDN'T add a separate mode for .dir-locals.el

[Clément Pit-Claudel]

On 2019-10-19 08:28, Alan Mackenzie wrote:
> Answer; NOTHING!  I want all the facilities of Emacs Lisp Mode whilst
> editing a .dir-locals.el, not to have some overlord determine for me
> what I don't really want.

I anticipated this objection, to some extent, and that's partly why my original patch made dir-locals-mode inherit from emacs-lisp-mode.

But do you actually want warnings telling you that your file is missing a (provide '\.dir-locals) form and a ";;; .dir-locals.el ends here" line, as well as warning about a missing one-line package description at the top at the file, and a missing ";;; Code:" header?  These are part of "all the facilities of Emacs Lisp Mode" for people whol enable Flycheck and Flymake in that mode. 

Re: Why we SHOULDN'T add a separate mode for .dir-locals.el

[Dmitry Gutov]

On 19.10.2019 15:28, Alan Mackenzie wrote:
> Answer; NOTHING!  I want all the facilities of Emacs Lisp Mode whilst
> editing a .dir-locals.el, not to have some overlord determine for me
> what I don't really want.

It's a very lazy reply that can be tailored to almost any situation when 
you don't want to see something changed.

"I don't want some overlord [e.g. the author of a change proposal] 
determine for me what I <...> want"!

No, we don't want all the Emacs Lisp Mode facilities. We only want some 
of them, and others, we want at least slightly modified.