bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: bug#40573: 27.0.90; flymake-mode broken in scratch buffer
Date: Tue, 14 Apr 2020 13:56:28 +0100

On Tue, Apr 14, 2020 at 1:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Tue, 14 Apr 2020 12:48:55 +0100
> > Cc: Juri Linkov <juri@linkov.net>, 40573@debbugs.gnu.org,
> >       Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>
> >
> >  It is only important if we want this new mode to be turned on
> >  automatically in such files.  If we want these files to be visited in
> >  Fundamental mode, or some other random mode due to their extensions,
> >  then this is indeed not important.  But then .dir-locals.el, for
> >  example, will be visited in emacs-lisp-mode, something I thought we
> >  wanted to prevent?
> >
> > Yes, we do.  And it's trivial to add an entry for .dir-locals.el
> > to auto-mode-alist for that, as was suggested often. In hindsight
> > choosing .el for that file wasn't great, but it's not very bad either.
> >
> > For files under our control, we have more options, including
> > mode cookies and doing nothing.
>
> What I was getting at was that maybe there are other extensions that
> we'd like to trigger this mode.  Also, Emacs has means for
> automatically turning modes on, other than the file-name extension and
> the mode cookie.  Maybe some of them could be used in this case.

Do you mean magic-mode-alist?  Do you think you'd be able
to come up with something that won't yield a lot  of false
positives or a lot of false negatives?  If so, don't  let me
stop you.  But also don't let those ambitious stand in the way
of the new mode: they're not a prerequisite.

> >  We must have some body of common traits of these files to program a
> >  mode that is suitable for them.
> >
> > That's easy: lisp forms that can be `read`.
>
> I meant traits that are relevant to what major modes do:
> fontification, indentation, what is considered a defun, etc.

Sure, and I meant it's easier to think of them as subtraction
from the existing emacs-lisp-mode.  Ask yourself the inverse
question: what things _aren't_ relevant. The more things you
can confidently subtract, the closer you are to something
better than the current situation. You'll see it's much easier
than the exercise you're trying to make. I'd subtract flymake,
xref, eldoc and imenu, for starters. For font-lock I don't mind if
for the time being we use the same font-lock keywords.
Doesn't mean we can't tweak these things in the future,
of course.  But maybe you know of other low-hanging fruit
that only makes sense for elisp code.

Re. defun finding.  In general, there are no things
analogous to a defun in data files, there just aren't! Doesn't mean
we can't, in the future, derive new modes from lisp-data-mode
where such constructs make sense.  But for now, I'd add it to
"confidently subtract" list.

João




--
João Távora

reply via email to

[Prev in Thread] Current Thread [Next in Thread]