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

[João Távora]

Eli Zaretskii <address@hidden> writes:

>> From: João Távora <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> 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