Subject: bug#40573: 27.0.90; flymake-mode broken in scratch buffer

From: João Távora <[email-masked]>
Date: Sat, 18 Apr 2020 11:03:01 +0100

On Sat, Apr 18, 2020 at 10:28 AM Eli Zaretskii <[email-masked]> wrote:
> > From: João Távora <[email-masked]>
> > Date: Sat, 18 Apr 2020 09:26:59 +0100
> > Cc: Stefan Monnier <[email-masked]>, Juri Linkov <
[email-masked]>, [email-masked],
> >       Dmitry Gutov <[email-masked]>
> >
> > I've put "the code" in a branch in our repo, called
'scratch/add-lisp-data'.
>
> Thanks.  The backward-incompatible change in lisp-mode-variables is
> something I'd like to avoid.  Is it really necessary?

What is it backward-incompatible to?  As far as I can tell, it's an
internal lisp routine, not called by any code outside of Emacs core.
It's never been mentioned as an "Incompatible lisp change" in any
NEWS, ever.  It's mentioned briefly in the manual as an example
of a helper function that aids in writing modes, and the arguments
are quite irrelevant there. I can change that example to match the
reality, if you want.

If you're talking strictly about about keeping the calling convention
for any hypothetical user code that might be relying on it, we can
add `&rest dummy`.  But I can't really see the why.

Do you want me to do either of these 2 things?

> Also, what about .dir-locals-2.el?

I forgot about it. I'll add it to the auto-mode-alist in the next iteration.

> The tramp-persistency-file-name has a known fixed file name; why not
> add it to auto-mod-alist?  Likewise with eww's eww-bookmarks and
> saveplace's save-place-file (2 standard names).

I just thought it was simpler to add the cookie.  What's
the problem with that?  Maybe one day it ceases to
have that known file name, and less code has to be
touched.  Using auto-mode-alist is repeating oneself.
If one can avoid it it's a good idea.  Unless you're aware
of some disadvantage of cookies that I'm not seeing.

Anyway, I can surely switch to auto-mode-alist if you
insist, no problem. Do you insist in this?

> I also think we have
> many more similar Lisp data files mentioned in the core alone: I see a
> lot if I grep the Lisp files for "~/".

Sure, but I don't know which of those are Lisp data or not.  For
the set I edited, I relied on the feedback and the work of Juri
and Basil, who presumably know and work these files. I'm all for
extending lisp-data-mode to these files if someone (perhaps
some users or the authors of the extensions who produce
these files). But I don't use them, so I'm not the best person
to judge if they should have the cookie or not.

If you do use and know some of these files, I think I've shown
how trivial it is to make them use lisp-data-mode.

--
João Távora