GNU bug report logs - #40573
27.0.90; flymake-mode broken in scratch buffer

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>
Subject: bug#40573: 27.0.90; flymake-mode broken in scratch buffer
Date: Tue, 14 Apr 2020 09:48:43 +0100

[Message part 1 (text/plain, inline)]

On Tue, Apr 14, 2020 at 6:51 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > There are many other examples of ELisp data files.  One is already
> > mentioned .dir-locals.el that needs editing features from
> > emacs-lisp-mode (indentation, commenting, ...) as well,
> > but doesn't need the dynamic/lexical distinction.
>
> How would you propose to identify these files for turning on this
> special mode?  They don't seem to have a clear-cut set of extensions
> and/or file names.

One thing I don't understand is why is this important at all.

I normally work with the Common Lisp language.  When using that
language, ones uses COMMON-LISP:WRITE to record things persistently to
files that can be COMMON-LISP:READ back.  Being data files, these files
are edited only sporadically by humans because they are really meant to
be understood by programs executing on machines.  But when you do open
them manually, it is quite useful to automatically pair parenthesis,
fill comment paragraphs, understand strings, have sexp indentation, etc
etc.  Currently these files opens in fundamental-mode which has a syntax
table, and not much else.  It doesn't recognize comments, font-lock or
do any type of useful indentation.

I personally start up emacs-lisp-mode for them, and live with the
annoyance of bogus flymake, bogus eldoc, etc..

Common lispers are a minority, but people working with Clojure or Guile
will probably experience the same.  And of course people working with
Emacs Lisp will do so to.

And, by the way, if you're thinking that the new mode shouldn'tbe called
"emacs-lisp-data-mode" at all, but just "lisp-data-mode", then I fully
agree.  But I'm not bothered much that 'emacs' is in there, either: it
doesn't change how useful the mode is for me or anyone else using lisp
data files.

Anyway, the only thing that distinguishes these files from the rest of
the world's files is the fact that their contents can be `read` or
COMMON-LISP:READ or clojure.core/read.  There are not a lot of
"tell-tale signs".  Even a syntactic error such as a misplaced
parenthesis still doesn't remove the file from this class of files: we
still want to use a lisp-data-mode to edit them (and possibly to fix
that parenthesis).

It's a very large class of files.  I _don't_ expect Emacs to cleverly
turn on this new mode for every memeber of this class.  Though it would
be nice for Emacs to do this for _some_ members, presumably the ones it
is very sure about, such as dir-locals.el or recentf.  But for all the
others:

1. If Emacs produces them, then we can change Emacs it to add a mode
cookie to the top or trailer of the file;  auto-mode-alist to
record that file; or do nothing.

2. If Emacs doesn't produce them, then users are responsible for them.
We can recommend that they add a cookie or use auto-mode-alist or
magic-mode-alist.

Even if we chose to do nothing every time, we will have still greatly
improved the situation.

As to _how_ the new mode is to be implemented, you'll see it's a very
simple change.  Simpler than your dir-locals.el-specific fix and fixes a
much wider array of situations.

Stefan's patch is a good starting point:

  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00736.html

Even the documentation for this would be simple to write.

> Thanks for the other details, I think this is very useful.

Examples such as recentf, tramp, and ido files had already been given.
Again please don't base any implementation on those "details": they are
just an example.  The universe of lisp data files is much greater than
that.

--
João Távora

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.