From: Eli Zaretskii <eliz@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Add a separate mode for .dir-locals.el
Date: Sat, 19 Oct 2019 17:03:41 +0300 [thread overview]
Message-ID: <83bluc7rya.fsf@gnu.org> (raw)
In-Reply-To: <CALDnm520xMnARzHEFxR7ZktjfQZawDtryyu6gVD+q1QwaAe1Uw@mail.gmail.com> (message from João Távora on Sat, 19 Oct 2019 14:36:21 +0100)
> 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.
next prev parent reply other threads:[~2019-10-19 14:03 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83bluc7rya.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=cpitclaudel@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).