From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Add a separate mode for .dir-locals.el
Date: Fri, 18 Oct 2019 14:43:36 +0100 [thread overview]
Message-ID: <jjb36fqqid3.fsf@gmail.com> (raw)
In-Reply-To: <83d0eu8c80.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Oct 2019 15:33:35 +0300")
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
next prev parent reply other threads:[~2019-10-18 13:43 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 2:07 Add a separate mode for .dir-locals.el Clément Pit-Claudel
2019-10-17 2:20 ` Lars Ingebrigtsen
2019-10-17 7:53 ` Eli Zaretskii
2019-10-17 11:51 ` Clément Pit-Claudel
2019-10-17 12:21 ` João Távora
2019-10-17 13:16 ` Eli Zaretskii
2019-10-17 13:51 ` Clément Pit-Claudel
2019-10-17 15:45 ` Yuri Khan
2019-10-17 15:47 ` Clément Pit-Claudel
2019-10-17 16:55 ` Amin Bandali
2019-10-17 14:00 ` João Távora
2019-10-17 15:12 ` Dmitry Gutov
2019-10-17 15:32 ` Stefan Monnier
2019-10-17 15:41 ` João Távora
2019-10-17 15:47 ` Clément Pit-Claudel
2019-10-17 16:37 ` Stefan Monnier
2019-10-17 17:04 ` João Távora
2019-10-17 17:35 ` Eli Zaretskii
2019-10-17 17:42 ` João Távora
2019-10-17 17:52 ` Eli Zaretskii
2019-10-17 18:09 ` João Távora
2019-10-17 18:28 ` Eli Zaretskii
2019-10-17 19:00 ` João Távora
2019-10-17 19:21 ` Eli Zaretskii
2019-10-17 19:53 ` Stefan Monnier
2019-10-18 7:39 ` Eli Zaretskii
2019-10-18 12:56 ` Stefan Monnier
2019-10-17 21:35 ` João Távora
2019-10-18 8:00 ` Eli Zaretskii
2019-10-18 8:38 ` Juanma Barranquero
2019-10-18 13:14 ` Stefan Monnier
2019-10-18 10:25 ` João Távora
2019-10-18 12:33 ` Eli Zaretskii
2019-10-18 13:43 ` João Távora [this message]
2019-10-18 14:07 ` Dmitry Gutov
2019-10-19 9:52 ` Eli Zaretskii
2019-10-19 11:00 ` João Távora
2019-10-19 11:08 ` João Távora
2019-10-19 11:56 ` Eli Zaretskii
2019-10-19 12:55 ` Clément Pit-Claudel
2019-10-19 13:36 ` João Távora
2019-10-19 14:03 ` Eli Zaretskii
2019-10-19 16:13 ` João Távora
2019-10-19 12:53 ` Clément Pit-Claudel
2019-10-19 14:14 ` Eli Zaretskii
2019-10-19 16:51 ` Clément Pit-Claudel
2019-10-19 20:41 ` Dmitry Gutov
2019-10-19 21:35 ` Alan Mackenzie
2019-10-19 22:01 ` Dmitry Gutov
2019-10-20 5:45 ` Eli Zaretskii
2019-10-20 8:17 ` João Távora
2019-10-20 15:40 ` Juri Linkov
2019-10-20 19:29 ` João Távora
2019-10-21 12:43 ` Dmitry Gutov
2019-10-21 13:15 ` Eli Zaretskii
2019-10-21 13:34 ` Dmitry Gutov
2019-10-21 13:41 ` João Távora
2019-10-21 13:48 ` Eli Zaretskii
2019-10-19 20:38 ` Dmitry Gutov
2019-10-20 5:38 ` Eli Zaretskii
2019-10-20 20:21 ` Dmitry Gutov
2019-10-21 6:24 ` Eli Zaretskii
2019-10-21 7:05 ` João Távora
2019-10-21 7:15 ` Eli Zaretskii
2019-10-21 8:25 ` João Távora
2019-10-21 10:09 ` Eli Zaretskii
2019-10-21 10:28 ` João Távora
2019-10-21 10:59 ` Eli Zaretskii
2019-10-21 11:22 ` João Távora
2019-10-21 11:32 ` Eli Zaretskii
2019-10-21 11:39 ` João Távora
2019-10-21 12:26 ` Dmitry Gutov
2019-10-17 19:50 ` Stefan Monnier
2019-10-17 19:59 ` Eli Zaretskii
2019-10-17 20:32 ` Stefan Monnier
2019-10-18 7:34 ` Michael Albinus
2019-10-18 7:52 ` Eli Zaretskii
2019-10-18 13:11 ` Stefan Monnier
2019-10-19 10:00 ` Eli Zaretskii
2019-10-19 14:05 ` Stefan Monnier
2019-10-17 16:36 ` Eli Zaretskii
2019-10-17 17:47 ` Alan Mackenzie
2019-10-17 18:08 ` Stefan Monnier
2019-10-17 19:46 ` Alan Mackenzie
2019-10-17 20:19 ` Stefan Monnier
2019-10-17 18:19 ` João Távora
2019-10-17 19:38 ` Alan Mackenzie
[not found] ` <CALDnm50Q+QuhYRqZxV4-YzAAqhmU05+nOS3Oh1wvcJsYEX+sbg@mail.gmail.com>
2019-10-17 14:12 ` Eli Zaretskii
2019-10-17 15:31 ` João Távora
2019-10-17 8:55 ` Andreas Schwab
2019-10-17 11:48 ` Clément Pit-Claudel
2019-10-17 12:03 ` Andreas Schwab
2019-10-17 12:10 ` Clément Pit-Claudel
2019-10-18 3:14 ` Richard Stallman
2019-10-17 13:40 ` Stefan Monnier
2019-10-19 12:28 ` Why we SHOULDN'T add " Alan Mackenzie
2019-10-19 12:59 ` Clément Pit-Claudel
2019-10-19 22:04 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jjb36fqqid3.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=cpitclaudel@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.