GNU bug report logs -
#40573
27.0.90; flymake-mode broken in scratch buffer
Previous Next
Reported by: João Távora <joaotavora <at> gmail.com>
Date: Sun, 12 Apr 2020 13:20:02 UTC
Severity: normal
Found in version 27.0.90
Done: João Távora <joaotavora <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40573 in the body.
You can then email your comments to 40573 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 13:20:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
João Távora <joaotavora <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 12 Apr 2020 13:20:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Eli, remember when you added this commit?
commit 61fb5214816ef3d57e676d900e499ffcd079a1f9
Author: Eli Zaretskii <eliz <at> gnu.org>
Date: Mon Oct 21 14:29:13 2019 +0300
Avoid false indications from Flymake in .dir-locals.el files
This seems to have the unintended effect of also disabling flymake-mode
in fileless elisp buffers, like *scratch*. Was it intended? It seems like
a
regression in relation to 26.3. The repro is simple:
Emacs -Q
M-x flymake-mode
Works in Emacs 26.3, doesn't in Emacs-27.
Again, without wanting to rehash a long and difficult discussion, I
think the best way to fix the original problem is to make an
emacs-lisp-data-mode and use that mode for .dir-locals.el.
emacs-lisp-data-mode ; things related to
^ ; emacs-lisp-data, like sexp navigation,
| ; comments, etc. Use for .dir-locals.el
|
|
emacs-lisp-mode ; things related to data which happens
^ ; to also be code. Setup xref, flymake, imenu,
| ; etc
|
|
lisp-interaction-mode ; no change, basically this just has an
; enhanced keymap for for the advanced
; interaction possibilities.
That said, whatever fix we can come up with for this regression is
probably safer for Emacs 27. I propose this slight convolution of the
condition you added.
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 2617a6e4cc..f39ecf9b7b 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -264,9 +264,9 @@ emacs-lisp-mode
(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)))
+ (and (stringp fname)
+ (or (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)))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 13:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sun, 12 Apr 2020 14:18:50 +0100
>
> That said, whatever fix we can come up with for this regression is
> probably safer for Emacs 27. I propose this slight convolution of the
> condition you added.
Thanks, this is okay for the emacs-27 branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 14:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 12, 2020 at 2:48 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Thanks, this is okay for the emacs-27 branch.
Done, just pushed. Not marking the bug done, though, since
as I said before, I don't think this is the right fix. Or maybe
it should be marked done but not closed? I don't know these
bug state transition dynamics and won't object to anything
you want to do here.
Thanks,
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 14:45:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sun, 12 Apr 2020 15:24:03 +0100
> Cc: 40573 <at> debbugs.gnu.org
>
> On Sun, Apr 12, 2020 at 2:48 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Thanks, this is okay for the emacs-27 branch.
>
> Done, just pushed. Not marking the bug done, though, since
> as I said before, I don't think this is the right fix.
Why isn't this the right fix?
> Or maybe it should be marked done but not closed? I don't know these
> bug state transition dynamics and won't object to anything you want
> to do here.
There's no such thing as done but not closed. Feel free to leave this
open if you intend to work on it on master.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 17:03:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 12, 2020 at 3:44 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Thanks, this is okay for the emacs-27 branch.
> > Done, just pushed. Not marking the bug done, though, since
> > as I said before, I don't think this is the right fix.
>
> Why isn't this the right fix?
>
Because the right fix is not to have the condition at
the end of emacs-lisp-mode at all, as I explained
in the previous email. I.e handicapping a mode depending
on the buffer file name the mode applies to is wrong. IMO.
> > Or maybe it should be marked done but not closed? I don't know these
> > bug state transition dynamics and won't object to anything you want
> > to do here.
>
> There's no such thing as done but not closed. Feel free to leave this
> open if you intend to work on it on master.
>
The only intention I have is to revert the commit you added,
add an emacs-lisp-data-mode according to Stefan's and Dmitry's
suggestion, and use that mode for .dir-local.el. I'd also appreciate
such a mode for other lispy data files I have. Anyway, last time
I checked, you opposed this (very?) strongly so unless that stance
has changed, there's not much for me to work on.
Let me know,
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 17:18:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sun, 12 Apr 2020 18:02:31 +0100
> Cc: 40573 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> Why isn't this the right fix?
>
> Because the right fix is not to have the condition at
> the end of emacs-lisp-mode at all, as I explained
> in the previous email. I.e handicapping a mode depending
> on the buffer file name the mode applies to is wrong. IMO.
So you want to restart all that old dispute from last October? My
opinion didn't change.
> The only intention I have is to revert the commit you added,
> add an emacs-lisp-data-mode according to Stefan's and Dmitry's
> suggestion, and use that mode for .dir-local.el. I'd also appreciate
> such a mode for other lispy data files I have. Anyway, last time
> I checked, you opposed this (very?) strongly so unless that stance
> has changed, there's not much for me to work on.
My opinion on adding such mode for this one issue hasn't changed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 12 Apr 2020 17:52:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 12, 2020 at 6:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Sun, 12 Apr 2020 18:02:31 +0100
> > Cc: 40573 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > Why isn't this the right fix?
> >
> > Because the right fix is not to have the condition at
> > the end of emacs-lisp-mode at all, as I explained
> > in the previous email. I.e handicapping a mode depending
> > on the buffer file name the mode applies to is wrong. IMO.
>
> So you want to restart all that old dispute from last October? My
> opinion didn't change.
>
I believe I was answering your question.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 13 Apr 2020 00:19:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> The only intention I have is to revert the commit you added,
> add an emacs-lisp-data-mode according to Stefan's and Dmitry's
> suggestion, and use that mode for .dir-local.el. I'd also appreciate
> such a mode for other lispy data files I have. Anyway, last time
> I checked, you opposed this (very?) strongly so unless that stance
> has changed, there's not much for me to work on.
Please add emacs-lisp-data-mode. I have data buffers in emacs-lisp mode
permanently visited all the time, and in the Buffer List the modes
of these buffers "ELisp/d" are highlighted with the warning face.
It's fine to encourage the users to convert emacs-lisp files
from dynamic (the suffix "/d" in mode name highlighted as a warning)
to lexical (the suffix "/l" unhighlighted).
But the problem is that these files are emacs-lisp data files,
they can't be converted to lexical-binding, they need a special data mode.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 13 Apr 2020 04:37:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 40573 <at> debbugs.gnu.org, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 13 Apr 2020 02:58:07 +0300
>
> Please add emacs-lisp-data-mode. I have data buffers in emacs-lisp mode
> permanently visited all the time, and in the Buffer List the modes
> of these buffers "ELisp/d" are highlighted with the warning face.
>
> It's fine to encourage the users to convert emacs-lisp files
> from dynamic (the suffix "/d" in mode name highlighted as a warning)
> to lexical (the suffix "/l" unhighlighted).
>
> But the problem is that these files are emacs-lisp data files,
> they can't be converted to lexical-binding, they need a special data mode.
As I said in that old discussion, I'm not opposed to such a mode, if
it supports more than just running Flymake in .dir-locals.el. If you
have a bunch of other files for which such a mode could be useful,
please describe the files, their names or other telltale indications
(to be used for turning on this mode), and their special needs that
distinguish them from ELisp source files. Also, if you have some
wishes for commands special to such files, or how the behavior of the
existing commands should differ in such files, please tell that as
well.
IOW, such a mode should solve some real problems, not just a single
glitch of turning on Flymake and producing annoying warnings in a file
of a single name.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 13 Apr 2020 23:29:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> As I said in that old discussion, I'm not opposed to such a mode, if
> it supports more than just running Flymake in .dir-locals.el. If you
> have a bunch of other files for which such a mode could be useful,
> please describe the files, their names or other telltale indications
> (to be used for turning on this mode), and their special needs that
> distinguish them from ELisp source files. Also, if you have some
> wishes for commands special to such files, or how the behavior of the
> existing commands should differ in such files, please tell that as
> well.
All files in http://git.savannah.nongnu.org/cgit/ee.git/tree/view
are ELisp data files. They contain Lisp data lists including
alists with some code in lambdas. Here is an example from
http://git.savannah.nongnu.org/cgit/ee.git/tree/view/buffers.ee
[((type . view)
(name . "by Recency/list-buffers")
(description . "emulates the default display of function `list-buffers'")
(r-filter . (lambda (r)
(let ((buffer-name (ee-field 'buffer-name r)))
(not (or (and (> (length buffer-name) 0) (eq (aref buffer-name 0) ?\040))
(equal (ee-buffers-buffer-name) buffer-name))))))
These files need font-locking from emacs-lisp-mode for viewing, and other
features of emacs-lisp-mode for editing: indentation, commenting, etc.
i.e. everything from emacs-lisp-mode except code evaluation. This is
one difference between emacs-lisp-data-mode and emacs-lisp-mode.
Another difference is that distinction between dynamic/lexical binding
makes no sense for ELisp data files. It's wrong to use "ELisp/d" as
a mode name for ELisp data files where "/d" indicates dynamic binding.
A new mode could help to solve these problems, so ELisp data files could
enable emacs-lisp-data-mode regardless of their file extension. e.g.
http://git.savannah.nongnu.org/cgit/ee.git/tree/ee-datafile.el
currently assigns emacs-lisp-mode:
(add-to-list 'auto-mode-alist '("\\.ee\\'" . emacs-lisp-mode))
but could use emacs-lisp-data-mode instead:
(add-to-list 'auto-mode-alist '("\\.ee\\'" . emacs-lisp-data-mode))
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.
More ELisp data files can be found in ~/.emacs.d/
Here are some examples with short excerpts:
1. ~/.emacs.d/elpa/archives/gnu/archive-contents
(ace-window .
[(0 9 0)
((avy
(0 2 0)))
"Quickly switch windows." single
((:keywords "window" "location")
2. ~/.emacs.d/bookmarks
;;;; Emacs Bookmark Format Version 1 ;;;; -*- coding: utf-8-emacs -*-
;;; This format is meant to be slightly human-readable;
;;; nevertheless, you probably don't want to edit it.
;;; -*- End Of Bookmark File Format Version Stamp -*-
3. ~/.emacs.d/tramp
;; -*- emacs-lisp -*-
;; Tramp connection history. Don't change this file.
;; Run `M-x tramp-cleanup-all-connections' instead.
4. ~/.emacs.d/places
All these data files have one difference from ELisp code files:
they are not loaded with evaluation. For example, code that reads
~/.emacs.d/places looks like
(let ((file (expand-file-name save-place-file)))
(if (file-readable-p file)
(with-current-buffer (get-buffer-create " *Saved Places*")
(delete-region (point-min) (point-max))
(insert-file-contents file)
They all could benefit from a dedicated emacs-lisp-data-mode.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 05:52:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: joaotavora <at> gmail.com, 40573 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> dgutov <at> yandex.ru
> Date: Tue, 14 Apr 2020 02:17:11 +0300
>
> These files need font-locking from emacs-lisp-mode for viewing, and other
> features of emacs-lisp-mode for editing: indentation, commenting, etc.
> i.e. everything from emacs-lisp-mode except code evaluation. This is
> one difference between emacs-lisp-data-mode and emacs-lisp-mode.
>
> Another difference is that distinction between dynamic/lexical binding
> makes no sense for ELisp data files. It's wrong to use "ELisp/d" as
> a mode name for ELisp data files where "/d" indicates dynamic binding.
What do you propose to show as the mode-lighter instead?
> http://git.savannah.nongnu.org/cgit/ee.git/tree/ee-datafile.el
> currently assigns emacs-lisp-mode:
>
> (add-to-list 'auto-mode-alist '("\\.ee\\'" . emacs-lisp-mode))
>
> but could use emacs-lisp-data-mode instead:
>
> (add-to-list 'auto-mode-alist '("\\.ee\\'" . emacs-lisp-data-mode))
>
> 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.
Thanks for the other details, I think this is very useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 08:50:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 11:30:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Tue, 14 Apr 2020 09:48:43 +0100
> Cc: Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
>
> > 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.
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?
> 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.
We must have some body of common traits of these files to program a
mode that is suitable for them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 11:50:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 14, 2020 at 12:29 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Tue, 14 Apr 2020 09:48:43 +0100
> > Cc: Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <
> dgutov <at> yandex.ru>
> >
> > > 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.
>
> 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.
> 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.
>
> 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`.
But it's even easier to find that "suitable mode" if you think
about the problem differently, as a "differences to
emacs-lisp-mode" problem. Let me explain.
Basically we just need to split emacs-lisp-mode in two.
I'd say flymake and imenu and xref and eldoc stay in
emacs-lisp-mode, all the rest stays in lisp-data-mode.
After the inheritance is setup, emacs-lisp-mode is
unaffected, but lisp-data-mode can be used independently.
But if we don't get the "split point" right the first time, it's
very easy to move things across the border to get a better
lisp-data-mode _without_ adversely affecting emacs-lisp-mode
in any way.
Stefan's approach that I linked to is a good first approach
to that split point. Again, we can adjust it afterwards.
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 12:39:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Tue, 14 Apr 2020 12:48:55 +0100
> Cc: Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> 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.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 12:57:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 14, 2020 at 1:38 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Tue, 14 Apr 2020 12:48:55 +0100
> > Cc: Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <
dgutov <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 16:29:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Tue, 14 Apr 2020 13:56:28 +0100
> Cc: Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
>
> > 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?
That's one such feature, yes. There are others:
interpreter-mode-alist, auto-mode-interpreter-regexp, etc.
> 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.
I was just asking whether any of these can be relevant, that's all. A
negative answer is OK.
> > 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.
I was asking that aloud.
> Re. defun finding. In general, there are no things
> analogous to a defun in data files, there just aren't!
I think the example shown by Juri included a lambda-function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 16:43:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 14, 2020 at 5:28 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Re. defun finding. In general, there are no things
> > analogous to a defun in data files, there just aren't!
> I think the example shown by Juri included a lambda-function.
Then maybe that particular file is more than just lisp data,
just like some lisp data is emacs programs, and other
lisp data is clojure programs or scheme, where the definition
of a lambda function would look different. Or you could be looking
at a table of traditional dances and be looking at a misspelling
of the name of that curious brazilian one :-). My point is: the
data mode I'm proposing is completely agnostic to what a
"function" is. It shouldn't try to be clever about it.
Of course, you can derive an data-with-occasional-lambda-mode
and a traditional-dance-table-mode from it, to suit the particular
mode you're looking at. Then you can add defun-finding logic
to those modes, but not lisp-data-mode.
João
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Tue, 14 Apr 2020 20:06:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 40573 <at> debbugs.gnu.org (full text, mbox):
>> > Re. defun finding. In general, there are no things
>> > analogous to a defun in data files, there just aren't!
>> I think the example shown by Juri included a lambda-function.
I think the main issue should not be whether the file can contain Elisp
code somewhere, but whether the toplevel structure of the file is that
of Elisp code (i.e. whether it makes sense to pass it to `load` or
`byte-compile`).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Thu, 16 Apr 2020 22:05:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 40573 <at> debbugs.gnu.org (full text, mbox):
>> These files need font-locking from emacs-lisp-mode for viewing, and other
>> features of emacs-lisp-mode for editing: indentation, commenting, etc.
>> i.e. everything from emacs-lisp-mode except code evaluation. This is
>> one difference between emacs-lisp-data-mode and emacs-lisp-mode.
>>
>> Another difference is that distinction between dynamic/lexical binding
>> makes no sense for ELisp data files. It's wrong to use "ELisp/d" as
>> a mode name for ELisp data files where "/d" indicates dynamic binding.
>
> What do you propose to show as the mode-lighter instead?
Maybe "ELisp-Data" or more general "Lisp-Data".
> 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.
Each package could add its data file name to auto-mode-alist.
For example, bookmark.el could do something like:
(add-to-list 'auto-mode-alist (cons bookmark-default-file 'emacs-lisp-data-mode))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Thu, 16 Apr 2020 23:08:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> Each package could add its data file name to auto-mode-alist.
> For example, bookmark.el could do something like:
>
> (add-to-list 'auto-mode-alist (cons bookmark-default-file 'emacs-lisp-data-mode))
For generated files, it's probably better to add a -*- cookie in
the file.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 06:24:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: joaotavora <at> gmail.com, 40573 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> dgutov <at> yandex.ru
> Date: Fri, 17 Apr 2020 00:43:48 +0300
>
> >> Another difference is that distinction between dynamic/lexical binding
> >> makes no sense for ELisp data files. It's wrong to use "ELisp/d" as
> >> a mode name for ELisp data files where "/d" indicates dynamic binding.
> >
> > What do you propose to show as the mode-lighter instead?
>
> Maybe "ELisp-Data" or more general "Lisp-Data".
I meant the /d or /l suffix. I guess you are saying we shouldn't show
that because it makes no sense?
> > 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.
>
> Each package could add its data file name to auto-mode-alist.
> For example, bookmark.el could do something like:
>
> (add-to-list 'auto-mode-alist (cons bookmark-default-file 'emacs-lisp-data-mode))
SGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 06:50:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, joaotavora <at> gmail.com,
> 40573 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> Date: Thu, 16 Apr 2020 19:06:51 -0400
>
> > Each package could add its data file name to auto-mode-alist.
> > For example, bookmark.el could do something like:
> >
> > (add-to-list 'auto-mode-alist (cons bookmark-default-file 'emacs-lisp-data-mode))
>
> For generated files, it's probably better to add a -*- cookie in
> the file.
Right. But some modes define an init file that users need to create
and maintain.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 10:08:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 7:49 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, joaotavora <at> gmail.com,
> > 40573 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> > Date: Thu, 16 Apr 2020 19:06:51 -0400
> >
> > > Each package could add its data file name to auto-mode-alist.
> > > For example, bookmark.el could do something like:
> > >
> > > (add-to-list 'auto-mode-alist (cons bookmark-default-file
> 'emacs-lisp-data-mode))
> >
> > For generated files, it's probably better to add a -*- cookie in
> > the file.
>
> Right. But some modes define an init file that users need to create
> and maintain.
>
Right. But:
1. do we have a starting idea of which of those are mode-generated
and which of those are user-generated? And which can be either?
2. do we need to decide on this, admittedly nice-to-have behaviour,
before introducing the new major mode? Shouldn't we just take a
"best-effort" approach here?
João
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 10:14:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 11:07:15 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> 1. do we have a starting idea of which of those are mode-generated
> and which of those are user-generated? And which can be either?
Grepping our own sources for "~/" might be a good starting point.
> 2. do we need to decide on this, admittedly nice-to-have behaviour,
> before introducing the new major mode?
We don't need to, but it would be nice if that was supported from the
get-go (assuming it's needed).
> Shouldn't we just take a "best-effort" approach here?
I think you will find that opinions differ on what is "best effort" in
this context. Which is completely fine, we don't need to agree on
such issues.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 10:23:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 11:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Shouldn't we just take a "best-effort" approach here?
>
> I think you will find that opinions differ on what is "best effort" in
> this context. Which is completely fine, we don't need to agree on
> such issues.
>
Indeed, we don't need to, but here's my take on anyway,
followed by a question.
For me, best effort here means: do something self-contained
that brings some good and brings no harm. I think introducing
lisp-data-mode is _exactly_ in those conditions.
That's not to say we can't use do _more_ good as we
extend our efforts. But we shouldn't let those ambitions
stifle the initial deed, smaller, but unquestionably positive.
So I'm thinking of introducing lisp-data-mode later on in
master, following Stefan's patch. And using it only for `dir-locals.el`
for now (and for my own files of course).
Is that OK with you?
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 11:50:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 11:21:50 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> So I'm thinking of introducing lisp-data-mode later on in
> master, following Stefan's patch. And using it only for `dir-locals.el`
> for now (and for my own files of course).
>
> Is that OK with you?
No. IMO a mode included in the core should handle more that just one
kind of file. We've been through this, at least twice. Why do you
keep pushing? It only adds to aggravation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 11:58:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 12:49 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Fri, 17 Apr 2020 11:21:50 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
> juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > So I'm thinking of introducing lisp-data-mode later on in
> > master, following Stefan's patch. And using it only for `dir-locals.el`
> > for now (and for my own files of course).
> >
> > Is that OK with you?
>
> No. IMO a mode included in the core should handle more that just one
> kind of file. We've been through this, at least twice. Why do you
> keep pushing? It only adds to aggravation.
>
First, I don't know why you would feel aggravated by my
question. But I apologize anyway. I thought we were making
progress.
Anyway, maybe that wasn't clear, but the new mode would
handle lots of files I have here. It would allow me to design
better working methods for me and my team. I just can't show
you those files. But I hope you can take my word for it.
If you don't accept the "do no harm" criteria, how many
types of files produced by Emacs do you need before it
becomes useful in your criteria? Is .dir-locals.el + another
one enough? That's "more than just one".
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 13:06:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 12:57:22 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> No. IMO a mode included in the core should handle more that just one
> kind of file. We've been through this, at least twice. Why do you
> keep pushing? It only adds to aggravation.
>
> First, I don't know why you would feel aggravated by my
> question.
Not by the question, by your pushing and pushing and pushing, Same
arguments, same questions time and again. To what end?
> Anyway, maybe that wasn't clear, but the new mode would
> handle lots of files I have here. It would allow me to design
> better working methods for me and my team. I just can't show
> you those files. But I hope you can take my word for it.
I'd prefer to see the code.
> If you don't accept the "do no harm" criteria, how many
> types of files produced by Emacs do you need before it
> becomes useful in your criteria? Is .dir-locals.el + another
> one enough? That's "more than just one".
Again, this is not the kind of question that I can give a useful
answer. If you or someone else show the code, I'm sure I will be able
to make up my mind about it (and so will be others).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 14:45:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 40573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: João Távora <joaotavora <at> gmail.com>
>> Date: Fri, 17 Apr 2020 11:21:50 +0100
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>,
>> 40573 <at> debbugs.gnu.org,
>> Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> So I'm thinking of introducing lisp-data-mode later on in
>> master, following Stefan's patch. And using it only for `dir-locals.el`
>> for now (and for my own files of course).
>>
>> Is that OK with you?
>
> No. IMO a mode included in the core should handle more that just one
> kind of file.
FWIW, Juri pointed out some other files that could be placed in
lisp-data-mode in https://debbugs.gnu.org/40573#32:
> 1. ~/.emacs.d/elpa/archives/gnu/archive-contents
This would require adding a -*- mode -*- cookie in
package--download-one-archive, but this might complicate signature
checking.
> 2. ~/.emacs.d/bookmarks
This would require adding a -*- mode -*- cookie in
bookmark-insert-file-format-version-stamp.
> 3. ~/.emacs.d/tramp
This would require adding a -*- mode -*- cookie in
tramp-dump-connection-properties.
> 4. ~/.emacs.d/places
This would require adding a -*- mode -*- cookie in
save-place-alist-to-file.
Here are some more files of the same type in my own
user-emacs-directory:
5. nsm-settings-file
This would require adding a -*- mode -*- cookie in nsm-write-settings.
6. (expand-file-name "eww-bookmarks" eww-bookmarks-directory)
This would require adding a -*- mode -*- cookie in eww-write-bookmarks.
7. Possibly some EDE project files
Judging from:
(defclass ede-proj-project (...)
...
(file-header-line :initform ";; EDE Project Files are auto generated: Do Not Edit")
...)
But I don't use EDE so I can't say for sure.
> All these data files have one difference from ELisp code files:
> they are not loaded with evaluation.
They also differ in that they are all auto-generated and generally not
edited, but...
> They all could benefit from a dedicated emacs-lisp-data-mode.
...I sympathise with this.
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 15:22:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 2:05 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Fri, 17 Apr 2020 12:57:22 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > No. IMO a mode included in the core should handle more that just one
> > kind of file. We've been through this, at least twice. Why do you
> > keep pushing? It only adds to aggravation.
> >
> > First, I don't know why you would feel aggravated by my
> > question.
>
> Not by the question, by your pushing and pushing and pushing, Same
> arguments, same questions time and again. To what end?
The thing is, I give those arguments and you _don't_ refute
them. You don't say like: "oh but if we did that then this
negative effect would take place". Or "there isn't any positive
effects to what you suggest". So I assume my arguments
aren't getting through and I reformulate. That's not "pushing"
in my book. Also, don't assume the exasperation is only
on your side: I also get a bit exasperated when you don't
reply directly to my arguments.
> > Anyway, maybe that wasn't clear, but the new mode would
> > handle lots of files I have here. It would allow me to design
> > better working methods for me and my team. I just can't show
> > you those files. But I hope you can take my word for it.
> I'd prefer to see the code.
Which code? I can't show you my data files (but they're
not code). If you mean the one that adds the mode and
makes `.dir-locals.el` default to it, sure thing, I'll have it
ready later today. _that's_ what I was proposing earlier.
But please confirm this is the code you want to see.
> > If you don't accept the "do no harm" criteria, how many
> > types of files produced by Emacs do you need before it
> > becomes useful in your criteria? Is .dir-locals.el + another
> > one enough? That's "more than just one".
>
> Again, this is not the kind of question that I can give a useful
> answer. If you or someone else show the code, I'm sure I will be able
> to make up my mind about it (and so will be others).
The code I think you're talking about is Stefan's patch (that I
linked to) + adding an entry to `auto-mode-alist`. It introduces
the new mode and turns it on automatically on for a single
Emacs-produced file. I'll produce a formal patch of it later
today, but don't expect any surprises.
I'll present work in a branch, I'll be happy to add more code
for types of files. Though I was also suggesting that
this effort for more files could be done in master.
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 15:30:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 16:20:54 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> > Not by the question, by your pushing and pushing and pushing, Same
> > arguments, same questions time and again. To what end?
>
> The thing is, I give those arguments and you _don't_ refute
> them.
I do, but you just pretend not to understand. E.g., see below.
> > I'd prefer to see the code.
>
> Which code?
The code of the proposed new mode.
> If you mean the one that adds the mode and
> makes `.dir-locals.el` default to it, sure thing, I'll have it
> ready later today.
Once again, I don't want us to have a mode for .dir-locals.el files
alone. How many times do I have to say that before you understand?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 15:36:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 4:28 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Fri, 17 Apr 2020 16:20:54 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
> juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > > Not by the question, by your pushing and pushing and pushing, Same
> > > arguments, same questions time and again. To what end?
> >
> > The thing is, I give those arguments and you _don't_ refute
> > them.
>
> I do, but you just pretend not to understand. E.g., see below.
>
> > > I'd prefer to see the code.
> >
> > Which code?
>
> The code of the proposed new mode.
>
That has been shown already by Stefan's patch, way back.
I'm not going to add anything new to it. Maybe you can
speak of that patch.
> > If you mean the one that adds the mode and
> > makes `.dir-locals.el` default to it, sure thing, I'll have it
> > ready later today.
>
> Once again, I don't want us to have a mode for .dir-locals.el files
> alone. How many times do I have to say that before you understand?
>
Look Eli, there's no reason to be unpleasant, OK??? You said
"see the code". I asked you what the code was. You say you
want to see the code for the new mode. I'm going to show it to
you and others later on. I repeat *show*.
And you didn't refute ANY of my arguments. You just say you
don't want something to handle just one file. I and others point
to you it can be used for more files and YOU ignore it.
So let's get that straight, and let's let this rest for a while.
João
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 15:48:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 16:35:14 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> > Which code?
>
> The code of the proposed new mode.
>
> That has been shown already by Stefan's patch, way back.
And I already rejected it. If we want to have a mode, let's have a
mode, to support all the good features discussed lately here. Like a
lighter, code that injects the mode into auto-generated files and
turns on automatically for non-generated ones, etc. A clean job, IOW.
> Once again, I don't want us to have a mode for .dir-locals.el files
> alone. How many times do I have to say that before you understand?
>
> Look Eli, there's no reason to be unpleasant, OK???
I'm not being more unpleasant than you are.
> And you didn't refute ANY of my arguments. You just say you
> don't want something to handle just one file. I and others point
> to you it can be used for more files and YOU ignore it.
>
> So let's get that straight, and let's let this rest for a while.
I already had that straight, more than once. Please respect my
opinions on this. They are expressed in very clear words.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 15:56:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 17, 2020 at 4:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Fri, 17 Apr 2020 16:35:14 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
> juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > > Which code?
> >
> > The code of the proposed new mode.
> >
> > That has been shown already by Stefan's patch, way back.
>
> And I already rejected it. If we want to have a mode, let's have a
> mode, to support all the good features discussed lately here. Like a
> lighter, code that injects the mode into auto-generated files and
> turns on automatically for non-generated ones, etc. A clean job, IOW.
Can you explain what is dirty about having that mode for a subset
of files that _could_ make use of it and having the user select
it via M-x lisp-data-mode when he thinks it's useful? Can you give
evidence of any benefit to your all-or-nothing stance here?
I've explained, many times, that turning it on automatically for
non-generated files, is impossible to achieve. Do you disagree
with this statement? Maybe you do, perhaps you're seeing
something I don't or we're talking about different lisp-data-mode's.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 16:05:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 40573 <at> debbugs.gnu.org (full text, mbox):
>> 1. ~/.emacs.d/elpa/archives/gnu/archive-contents
>
> This would require adding a -*- mode -*- cookie in
> package--download-one-archive, but this might complicate signature
> checking.
I don't think it's worth modifying the file: the cookie could be placed
directly in the original file (i.e. in the file generated by the GNU
ELPA and MELPA scripts).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Fri, 17 Apr 2020 17:20:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 17 Apr 2020 16:55:07 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> Can you explain what is dirty about having that mode for a subset
> of files that _could_ make use of it and having the user select
> it via M-x lisp-data-mode when he thinks it's useful?
I already did, many times. I have nothing new to say about this.
> Can you give
> evidence of any benefit to your all-or-nothing stance here?
I don't have to give any evidence. We both have our opinions, and
they are different. Please respect mine.
> I've explained, many times, that turning it on automatically for
> non-generated files, is impossible to achieve. Do you disagree
> with this statement?
Yes, I do. Also mentioned more than once.
Can we please stop this futile going in circles?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 08:28:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've put "the code" in a branch in our repo, called 'scratch/add-lisp-data'.
It's also after my sig.
It's two commits. The first adds the mode, refactors some code around it
and sets it for dir-locals. The seconds sets it for 5 or 6 files. Thanks
Juri
and Basil, pointing directly to the function made it trivial easy to do!
The first commit is an evolution of Stefan's which makes a "lisp-data-mode"
instead of "emacs-lisp-data-mode". There's probably details I'm more than
willing to change if anyone wants, like not using the dir-locals-file
constant
in a place there, or not doing that setcar or those setf nth.
Anyway, I hope we can now talk about concrete stuff.
João
commit 035137bc92ec4b3ceab43409d4b8ea0deb975459
Author: João Távora <joaotavora <at> gmail.com>
Date: Sat Apr 18 09:04:13 2020 +0100
Use lisp-data-mode in 5 more places
Thanks to Juri Linkov and Basil L. Contovounesios for the list and the
indication of the function that needed to be changed.
* lisp/bookmark.el (bookmark-insert-file-format-version-stamp):
Use lisp-data-mode.
* lisp/saveplace.el (save-place-alist-to-file): Use
lisp-data-mode.
* lisp/net/eww.el (eww-write-bookmarks): Use lisp-data-mode.
* lisp/net/nsm.el (nsm-write-settings): Use lisp-data-mode.
* lisp/net/tramp-cache.el (tramp-dump-connection-properties): Use
lisp-data-mode.
diff --git a/lisp/bookmark.el b/lisp/bookmark.el
index 720ad18c16..f2384973e9 100644
--- a/lisp/bookmark.el
+++ b/lisp/bookmark.el
@@ -734,8 +734,10 @@ bookmark-insert-file-format-version-stamp
(if (memq (coding-system-base coding) '(undecided prefer-utf-8))
(setq coding 'utf-8-emacs))
(insert
- (format ";;;; Emacs Bookmark Format Version %d ;;;; -*- coding: %S
-*-\n"
- bookmark-file-format-version (coding-system-base coding)))
+ (format
+ ";;;; Emacs Bookmark Format Version %d\
+;;;; -*- coding: %S mode: lisp-data -*-\n"
+ bookmark-file-format-version (coding-system-base coding)))
(insert ";;; This format is meant to be slightly human-readable;\n"
";;; nevertheless, you probably don't want to edit it.\n"
";;; "
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index c83884fd25..a4544023f6 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -1733,7 +1733,7 @@ eww-add-bookmark
(defun eww-write-bookmarks ()
(with-temp-file (expand-file-name "eww-bookmarks"
eww-bookmarks-directory)
- (insert ";; Auto-generated file; don't edit\n")
+ (insert ";; Auto-generated file; don't edit -*- mode: lisp-data -*-\n")
(pp eww-bookmarks (current-buffer))))
(defun eww-read-bookmarks ()
diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 2d36c5e257..cc22427e6d 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -964,6 +964,7 @@ nsm-save-host
(defun nsm-write-settings ()
(with-temp-file nsm-settings-file
+ (insert ";;;; -*- mode: lisp-data -*-\n")
(insert "(\n")
(dolist (setting nsm-permanent-host-settings)
(insert " ")
diff --git a/lisp/net/tramp-cache.el b/lisp/net/tramp-cache.el
index 09e30f000f..6d87ce297b 100644
--- a/lisp/net/tramp-cache.el
+++ b/lisp/net/tramp-cache.el
@@ -472,7 +472,7 @@ tramp-dump-connection-properties
;; Dump it.
(with-temp-file tramp-persistency-file-name
(insert
- ";; -*- emacs-lisp -*-"
+ ";; -*- lisp-data -*-"
;; `time-stamp-string' might not exist in all Emacs flavors.
(condition-case nil
(progn
diff --git a/lisp/saveplace.el b/lisp/saveplace.el
index fa0e181bb1..f78639db24 100644
--- a/lisp/saveplace.el
+++ b/lisp/saveplace.el
@@ -248,7 +248,7 @@ save-place-alist-to-file
(delete-region (point-min) (point-max))
(when save-place-forget-unreadable-files
(save-place-forget-unreadable-files))
- (insert (format ";;; -*- coding: %s -*-\n"
+ (insert (format ";;; -*- coding: %s mode: lisp-data -*-\n"
(symbol-name coding-system-for-write)))
(let ((print-length nil)
(print-level nil))
commit b4af4a3578303741364dc91acdd5908d9b11e3a4
Author: João Távora <joaotavora <at> gmail.com>
Date: Sat Apr 18 02:46:04 2020 +0100
Add a lisp-data-mode for editing non-code lisp data
To provide a cleaner implementation remove arguments from the
auxiliary routine lisp-mode-variables. The modes/functions that need
to do some something special adjustment do them in their own bodies.
* lisp/chistory.el (command-history-mode): Don't pass nil to
lisp-mode-variables.
* lisp/files.el (auto-mode-alist): Add entry for ".dir-locals".
* lisp/help-fns.el (describe-variable): Don't pass useless args to
lisp-mode-variables.
* lisp/emacs-lisp/pp.el (pp-to-string): Don't pass useless args to
lisp-mode-variables.
* lisp/emacs-lisp/lisp-mode.el (lisp-mode-variables):
Simplify. Always set same variables.
(lisp-data-mode): New major mode.
(lisp-mode): Inherit from lisp-data-mode. Set special lisp-mode
stuff here.
* lisp/progmodes/elisp-mode.el (emacs-lisp-mode): Inherit from
lisp-data-mode.
(emacs-lisp-mode): Simplify.
* lisp/progmodes/inf-lisp.el (inferior-lisp-mode): Set the needed
syntax table here, not through other function.
diff --git a/lisp/chistory.el b/lisp/chistory.el
index c9aa927b94..485515d07b 100644
--- a/lisp/chistory.el
+++ b/lisp/chistory.el
@@ -139,7 +139,7 @@ command-history-mode
Keybindings:
\\{command-history-mode-map}"
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set (make-local-variable 'revert-buffer-function)
'command-history-revert)
(set-syntax-table emacs-lisp-mode-syntax-table))
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index 3b0f5493ee..8f7e6c0431 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -611,15 +611,8 @@ lisp-adaptive-fill
;; a single docstring. Let's fix it here.
(if (looking-at "\\s-+\"[^\n\"]+\"\\s-*$") ""))
-(defun lisp-mode-variables (&optional lisp-syntax keywords-case-insensitive
- elisp)
- "Common initialization routine for lisp modes.
-The LISP-SYNTAX argument is used by code in inf-lisp.el and is
-\(uselessly) passed from pp.el, chistory.el, gnus-kill.el and
-score-mode.el. KEYWORDS-CASE-INSENSITIVE non-nil means that for
-font-lock keywords will not be case sensitive."
- (when lisp-syntax
- (set-syntax-table lisp-mode-syntax-table))
+(defun lisp-mode-variables ()
+ "Common initialization routine for lisp modes."
(setq-local paragraph-ignore-fill-prefix t)
(setq-local fill-paragraph-function 'lisp-fill-paragraph)
(setq-local adaptive-fill-function #'lisp-adaptive-fill)
@@ -643,21 +636,24 @@ lisp-mode-variables
(setq-local multibyte-syntax-as-symbol t)
;; (setq-local syntax-begin-function 'beginning-of-defun) ;;Bug#16247.
(setq font-lock-defaults
- `(,(if elisp '(lisp-el-font-lock-keywords
- lisp-el-font-lock-keywords-1
- lisp-el-font-lock-keywords-2)
- '(lisp-cl-font-lock-keywords
- lisp-cl-font-lock-keywords-1
- lisp-cl-font-lock-keywords-2))
- nil ,keywords-case-insensitive nil nil
- (font-lock-mark-block-function . mark-defun)
- (font-lock-extra-managed-props help-echo)
- (font-lock-syntactic-face-function
- . lisp-font-lock-syntactic-face-function)))
+ (list nil nil nil nil nil
+ '(font-lock-mark-block-function . mark-defun)
+ '(font-lock-extra-managed-props help-echo)
+ '(font-lock-syntactic-face-function
+ . lisp-font-lock-syntactic-face-function)))
(setq-local prettify-symbols-alist lisp-prettify-symbols-alist)
(setq-local electric-pair-skip-whitespace 'chomp)
(setq-local electric-pair-open-newline-between-pairs nil))
+;;;###autoload
+(define-derived-mode lisp-data-mode prog-mode "Lisp-Data"
+ "Major mode for buffers holding data written in Lisp syntax."
+ :group 'lisp
+ (lisp-mode-variables)
+ (set-syntax-table lisp-mode-syntax-table)
+ (setq-local electric-quote-string t)
+ (setq imenu-case-fold-search nil))
+
(defun lisp-outline-level ()
"Lisp mode `outline-level' function."
(let ((len (- (match-end 0) (match-beginning 0))))
@@ -737,7 +733,7 @@ lisp-mode-map
"Keymap for ordinary Lisp mode.
All commands in `lisp-mode-shared-map' are inherited by this map.")
-(define-derived-mode lisp-mode prog-mode "Lisp"
+(define-derived-mode lisp-mode lisp-data-mode "Lisp"
"Major mode for editing Lisp code for Lisps other than GNU Emacs Lisp.
Commands:
Delete converts tabs to spaces as it moves back.
@@ -746,7 +742,11 @@ lisp-mode
\\{lisp-mode-map}
Note that `run-lisp' may be used either to start an inferior Lisp job
or to switch back to an existing one."
- (lisp-mode-variables nil t)
+ (setf
+ (nth 0 font-lock-defaults) '(lisp-cl-font-lock-keywords
+ lisp-cl-font-lock-keywords-1
+ lisp-cl-font-lock-keywords-2)
+ (nth 2 font-lock-defaults) t)
(setq-local lisp-indent-function 'common-lisp-indent-function)
(setq-local find-tag-default-function 'lisp-find-tag-default)
(setq-local comment-start-skip
diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 3df7b0e368..4d8bf52934 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -42,7 +42,7 @@ pp-to-string
OBJECT can be any Lisp object. Quoting characters are used as needed
to make output that `read' can handle, whenever this is possible."
(with-temp-buffer
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set-syntax-table emacs-lisp-mode-syntax-table)
(let ((print-escape-newlines pp-escape-newlines)
(print-quoted t))
diff --git a/lisp/files.el b/lisp/files.el
index fa72e51c49..a769d061f9 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -2657,6 +2657,9 @@ auto-mode-alist
("\\.ltx\\'" . latex-mode)
("\\.dtx\\'" . doctex-mode)
("\\.org\\'" . org-mode)
+ ;; .dir-locals.el is not really elisp. Can't use the
+ ;; `dir-locals-file' constant since that is defined below.
+ (".dir-locals.el" . lisp-data-mode)
("\\.el\\'" . emacs-lisp-mode)
("Project\\.ede\\'" . emacs-lisp-mode)
("\\.\\(scm\\|stk\\|ss\\|sch\\)\\'" . scheme-mode)
diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 0a99b8d6a3..dbf2cb807b 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -1000,7 +1000,7 @@ describe-variable
(terpri)
(let ((buf (current-buffer)))
(with-temp-buffer
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set-syntax-table emacs-lisp-mode-syntax-table)
(insert print-rep)
(pp-buffer)
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index f85fd771ca..2f231781ba 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -250,7 +250,7 @@ elisp--dynlex-modeline-map
map))
;;;###autoload
-(define-derived-mode emacs-lisp-mode prog-mode
+(define-derived-mode emacs-lisp-mode lisp-data-mode
`("ELisp"
(lexical-binding (:propertize "/l"
help-echo "Using lexical-binding mode")
@@ -268,35 +268,26 @@ emacs-lisp-mode
\\{emacs-lisp-mode-map}"
:group 'lisp
(defvar project-vc-external-roots-function)
- (lisp-mode-variables nil nil 'elisp)
+ (setcar font-lock-defaults
+ '(lisp-el-font-lock-keywords
+ lisp-el-font-lock-keywords-1
+ lisp-el-font-lock-keywords-2))
+ (set-syntax-table emacs-lisp-mode-syntax-table)
(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-hook 'eldoc-documentation-functions
#'elisp-eldoc-documentation-function nil t)
(add-hook 'xref-backend-functions #'elisp--xref-backend nil t)
(setq-local project-vc-external-roots-function #'elisp-load-path-roots)
(add-hook 'completion-at-point-functions
#'elisp-completion-at-point nil 'local)
- ;; .dir-locals.el and lock files will 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 teaching elisp-mode about files that only hold data
- ;; structures, we disable the ELisp Flymake backend for these files.
- (unless
- (let* ((bfname (buffer-file-name))
- (fname (and (stringp bfname) (file-name-nondirectory
bfname))))
- (and (stringp fname)
- (or (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)))
+ (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
+ (add-hook 'flymake-diagnostic-functions
+ #'elisp-flymake-byte-compile nil t))
;; Font-locking support.
diff --git a/lisp/progmodes/inf-lisp.el b/lisp/progmodes/inf-lisp.el
index 9f34a377f4..aa6c718041 100644
--- a/lisp/progmodes/inf-lisp.el
+++ b/lisp/progmodes/inf-lisp.el
@@ -274,7 +274,8 @@ inferior-lisp-mode
to continue it."
(setq comint-prompt-regexp inferior-lisp-prompt)
(setq mode-line-process '(":%s"))
- (lisp-mode-variables t)
+ (set-syntax-table lisp-mode-syntax-table)
+ (lisp-mode-variables)
(setq comint-get-old-input (function lisp-get-old-input))
(setq comint-input-filter (function lisp-input-filter)))
On Fri, Apr 17, 2020 at 6:19 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Fri, 17 Apr 2020 16:55:07 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
> juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > Can you explain what is dirty about having that mode for a subset
> > of files that _could_ make use of it and having the user select
> > it via M-x lisp-data-mode when he thinks it's useful?
>
> I already did, many times. I have nothing new to say about this.
>
> > Can you give
> > evidence of any benefit to your all-or-nothing stance here?
>
> I don't have to give any evidence. We both have our opinions, and
> they are different. Please respect mine.
>
> > I've explained, many times, that turning it on automatically for
> > non-generated files, is impossible to achieve. Do you disagree
> > with this statement?
>
> Yes, I do. Also mentioned more than once.
>
> Can we please stop this futile going in circles?
>
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 18 Apr 2020 09:26:59 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> Dmitry Gutov <dgutov <at> yandex.ru>
>
> 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?
Also, what about .dir-locals-2.el?
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 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 "~/".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 10:04:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 18, 2020 at 10:28 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Sat, 18 Apr 2020 09:26:59 +0100
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <
juri <at> linkov.net>, 40573 <at> debbugs.gnu.org,
> > Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 11:09:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 18 Apr 2020 11:03:01 +0100
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> > 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 isn't internal judging by its symbol, so it would be good not to
break compatibility, I think.
> 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.
It's just good practice. It prevents us from dealing with later
complaints and bug reports about breaking someone's code.
> Do you want me to do either of these 2 things?
If it isn't infeasible, please do.
> > 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?
Existing files was what I had in mind.
> Anyway, I can surely switch to auto-mode-alist if you
> insist, no problem. Do you insist in this?
Do I have to insist?
In any case, I didn't mean to use auto-mode-alist _instead_ odf adding
the cookie automatically, I meant to do it in addition.
> 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.
Sorry, I don't have time to do that research for now. Hopefully,
someone else will be able to do that.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 11:57:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 40573 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
>> 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.
Another candidate: Gnus score files, an example of whose format is given
in '(gnus) Score File Format'.
By default, they have have a file suffix of either ".SCORE" or ".ADAPT",
as determined by the user options gnus-score-file-suffix and
gnus-adaptive-file-suffix, respectively. Would these suffixes be unique
enough on their own to be added to auto-mode-alist? Perhaps
gnus-score.el could do this after evaluating the defcustoms.
As for automatically adding a -*- mode -*- cookie - my guess is that
gnus-score-save is the right place.
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 11:58:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 18, 2020 at 12:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> It isn't internal judging by its symbol, so it would be good not to
> break compatibility, I think.
Most of the code in Emacs doesn't follow the -- naming convention,
yet. There are no mentions to it in ELPA.
But indeed I've found some code in SLIME and SLY that uses it.
I know the maintainers of these packages well (one of them is
me) and will ensure there is no impact.
> > Do you want me to do either of these 2 things?
> If it isn't infeasible, please do.
OK.
> > I just thought it was simpler to add the cookie. What's
> > the problem with that?
> Existing files was what I had in mind.
OK. I admit I don't care much about those, but why not...
> > Anyway, I can surely switch to auto-mode-alist if you
> > insist, no problem. Do you insist in this?
> Do I have to insist?
Any problem with doing so? I'll interpret that as a "Yes".
> In any case, I didn't mean to use auto-mode-alist _instead_ odf adding
> the cookie automatically, I meant to do it in addition.
Ah, indeed I had misunderstood you. But what's the point
in having them also in the cookies then? That bit escapes me.
Anyway, I went and looked at the three files you mention, and
I discovered they're not "fixed" as I thought. They're defcustom
and defined way after auto-mode-alist, so we'd have to add-to-list,
contradicting the advice near auto-mode-alist. And the only way
we to safely do that add-to-list is to do it from :set directives
in the defcustom definition that mutates the auto-mode-alist
variable. If it's as complicated as I this, I don't think it's worth it.
So, while I don't oppose doing this, if you really insist I'd
appreciate you tell me how to do it or what you had in mind.
> > 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.
>
> Sorry, I don't have time to do that research for now. Hopefully,
> someone else will be able to do that.
Yes, let's be hopeful, though I don't yet know who cares about
this completeness as much as you.
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 12:04:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 18, 2020 at 12:56 PM Basil L. Contovounesios <contovob <at> tcd.ie>
wrote:
> gnus-adaptive-file-suffix, respectively. Would these suffixes be unique
> enough on their own to be added to auto-mode-alist? Perhaps
> gnus-score.el could do this after evaluating the defcustoms.
>
auto-mode-alist has comments near it that discourage it. I also
think we have to understand that auto-mode-alist has the potential
to introduce false positives. We don't want too many of those...
As for automatically adding a -*- mode -*- cookie - my guess is that
> gnus-score-save is the right place.
>
Awesome, thanks. Well if you're confident about your guess. I think
I've shown how easy it is to add them, so I'd personally feel free to
submit a patch or to push to that branch (or to add a git commit
and publish your branch somewhere else, if you don't have push
permissions).
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 12:36:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 18 Apr 2020 12:57:19 +0100
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> > > Anyway, I can surely switch to auto-mode-alist if you
> > > insist, no problem. Do you insist in this?
> > Do I have to insist?
>
> Any problem with doing so? I'll interpret that as a "Yes".
It's actually the other way around: if I don't feel my opinion is
strong enough, I usually say so.
> > In any case, I didn't mean to use auto-mode-alist _instead_ odf adding
> > the cookie automatically, I meant to do it in addition.
>
> Ah, indeed I had misunderstood you. But what's the point
> in having them also in the cookies then? That bit escapes me.
The cookies will take care of newly created/rewritten files,
auto-mode-alist will take care of existing ones that no one has
changed yet. The result is a more complete coverage of the involved
files.
> Anyway, I went and looked at the three files you mention, and
> I discovered they're not "fixed" as I thought. They're defcustom
> and defined way after auto-mode-alist, so we'd have to add-to-list,
No need for such complexity. I meant to mention the standard names in
auto-mode-alist, under the assumption that many/most users don't
change the default names.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 15:11:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 18, 2020 at 1:35 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > > why not add it to auto-mod-alist?
> > > > Anyway, I can surely switch to auto-mode-alist if you
> > > > insist, no problem. Do you insist in this?
> > > Do I have to insist?
> > Any problem with doing so? I'll interpret that as a "Yes".
> It's actually the other way around: if I don't feel my opinion is
> strong enough, I usually say so.
This is what actually-actually what happened: you asked "why
not add it to auto-mod-alist? " I answered and asked if you
insisted, because a question doesn't really sound imperative
to me. If it was an instrument of rhetoric, it wasn't very effective.
> > Anyway, I went and looked at the three files you mention, and
> > I discovered they're not "fixed" as I thought. They're defcustom
> > and defined way after auto-mode-alist, so we'd have to add-to-list,
>
> No need for such complexity. I meant to mention the standard names in
> auto-mode-alist, under the assumption that many/most users don't
> change the default names.
OK.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 23:37:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here's the final patch as a sum of all the commits in the
scratch/add-lisp-data-mode
branch. I fixed the small lisp-mode-variables backward incompatibility
issue.
Any comments/objections? Does this need documentation? Stefan,
you want to add an emacs-lisp-data-mode in between lisp-data-mode
and emacs-lisp-mode?
Thanks,
João
diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index df7458c3fb..fc68ee1b32 100644
--- b/doc/lispref/modes.texi
+++ a/doc/lispref/modes.texi
@@ -1356,9 +1356,9 @@
@smallexample
@group
-(defun lisp-mode-variables (&optional syntax keywords-case-insensitive
elisp)
- (when syntax
- (set-syntax-table lisp-mode-syntax-table))
+(defun lisp-mode-variables ()
+ "Common initialization routine for lisp modes."
+ (setq-local paragraph-ignore-fill-prefix t)
@dots{}
@end group
@end smallexample
@@ -1414,7 +1414,7 @@
@smallexample
@group
-(define-derived-mode lisp-mode prog-mode "Lisp"
+(define-derived-mode lisp-mode lisp-data-mode "Lisp"
"Major mode for editing Lisp code for Lisps other than GNU Emacs Lisp.
Commands:
Delete converts tabs to spaces as it moves back.
@@ -1425,7 +1425,7 @@
or to switch back to an existing one."
@end group
@group
- (lisp-mode-variables nil t)
+ (lisp-mode-variables)
(setq-local find-tag-default-function 'lisp-find-tag-default)
(setq-local comment-start-skip
"\\(\\(^\\|[^\\\n]\\)\\(\\\\\\\\\\)*\\)\\(;+\\|#|\\) *")
diff --git a/lisp/bookmark.el b/lisp/bookmark.el
index f2384973e9..720ad18c16 100644
--- b/lisp/bookmark.el
+++ a/lisp/bookmark.el
@@ -734,8 +734,10 @@
(if (memq (coding-system-base coding) '(undecided prefer-utf-8))
(setq coding 'utf-8-emacs))
(insert
- (format ";;;; Emacs Bookmark Format Version %d ;;;; -*- coding: %S
-*-\n"
- bookmark-file-format-version (coding-system-base coding)))
+ (format
+ ";;;; Emacs Bookmark Format Version %d\
+;;;; -*- coding: %S mode: lisp-data -*-\n"
+ bookmark-file-format-version (coding-system-base coding)))
(insert ";;; This format is meant to be slightly human-readable;\n"
";;; nevertheless, you probably don't want to edit it.\n"
";;; "
diff --git a/lisp/chistory.el b/lisp/chistory.el
index 485515d07b..c9aa927b94 100644
--- b/lisp/chistory.el
+++ a/lisp/chistory.el
@@ -139,7 +139,7 @@
Keybindings:
\\{command-history-mode-map}"
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set (make-local-variable 'revert-buffer-function)
'command-history-revert)
(set-syntax-table emacs-lisp-mode-syntax-table))
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index 13263f2fb5..3b0f5493ee 100644
--- b/lisp/emacs-lisp/lisp-mode.el
+++ a/lisp/emacs-lisp/lisp-mode.el
@@ -611,15 +611,10 @@
;; a single docstring. Let's fix it here.
(if (looking-at "\\s-+\"[^\n\"]+\"\\s-*$") ""))
-(defun lisp-mode-variables (&optional lisp-syntax keywords-case-insensitive
- elisp)
+(defun lisp-mode-variables (&rest ignored)
"Common initialization routine for lisp modes.
-The LISP-SYNTAX argument is used by code in inf-lisp.el and is
-\(uselessly) passed from pp.el, chistory.el, gnus-kill.el and
-score-mode.el. KEYWORDS-CASE-INSENSITIVE non-nil means that for
-font-lock keywords will not be case sensitive."
- (when lisp-syntax
- (set-syntax-table lisp-mode-syntax-table))
+Any number of parameters is accepted and ignored."
+ (set-syntax-table lisp-mode-syntax-table)
(setq-local paragraph-ignore-fill-prefix t)
(setq-local fill-paragraph-function 'lisp-fill-paragraph)
(setq-local adaptive-fill-function #'lisp-adaptive-fill)
@@ -643,21 +638,23 @@
(setq-local multibyte-syntax-as-symbol t)
;; (setq-local syntax-begin-function 'beginning-of-defun) ;;Bug#16247.
(setq font-lock-defaults
- `(,(if elisp '(lisp-el-font-lock-keywords
- lisp-el-font-lock-keywords-1
- lisp-el-font-lock-keywords-2)
- '(lisp-cl-font-lock-keywords
- lisp-cl-font-lock-keywords-1
- lisp-cl-font-lock-keywords-2))
- nil ,keywords-case-insensitive nil nil
- (font-lock-mark-block-function . mark-defun)
- (font-lock-extra-managed-props help-echo)
- (font-lock-syntactic-face-function
- . lisp-font-lock-syntactic-face-function)))
+ (list nil nil nil nil nil
+ '(font-lock-mark-block-function . mark-defun)
+ '(font-lock-extra-managed-props help-echo)
+ '(font-lock-syntactic-face-function
+ . lisp-font-lock-syntactic-face-function)))
(setq-local prettify-symbols-alist lisp-prettify-symbols-alist)
(setq-local electric-pair-skip-whitespace 'chomp)
(setq-local electric-pair-open-newline-between-pairs nil))
+;;;###autoload
+(define-derived-mode lisp-data-mode prog-mode "Lisp-Data"
+ "Major mode for buffers holding data written in Lisp syntax."
+ :group 'lisp
+ (lisp-mode-variables)
+ (setq-local electric-quote-string t)
+ (setq imenu-case-fold-search nil))
+
(defun lisp-outline-level ()
"Lisp mode `outline-level' function."
(let ((len (- (match-end 0) (match-beginning 0))))
@@ -737,7 +734,7 @@
"Keymap for ordinary Lisp mode.
All commands in `lisp-mode-shared-map' are inherited by this map.")
-(define-derived-mode lisp-mode prog-mode "Lisp"
+(define-derived-mode lisp-mode lisp-data-mode "Lisp"
"Major mode for editing Lisp code for Lisps other than GNU Emacs Lisp.
Commands:
Delete converts tabs to spaces as it moves back.
@@ -746,7 +743,11 @@
\\{lisp-mode-map}
Note that `run-lisp' may be used either to start an inferior Lisp job
or to switch back to an existing one."
- (lisp-mode-variables nil t)
+ (setf
+ (nth 0 font-lock-defaults) '(lisp-cl-font-lock-keywords
+ lisp-cl-font-lock-keywords-1
+ lisp-cl-font-lock-keywords-2)
+ (nth 2 font-lock-defaults) t)
(setq-local lisp-indent-function 'common-lisp-indent-function)
(setq-local find-tag-default-function 'lisp-find-tag-default)
(setq-local comment-start-skip
diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 4d8bf52934..3df7b0e368 100644
--- b/lisp/emacs-lisp/pp.el
+++ a/lisp/emacs-lisp/pp.el
@@ -42,7 +42,7 @@
OBJECT can be any Lisp object. Quoting characters are used as needed
to make output that `read' can handle, whenever this is possible."
(with-temp-buffer
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set-syntax-table emacs-lisp-mode-syntax-table)
(let ((print-escape-newlines pp-escape-newlines)
(print-quoted t))
diff --git a/lisp/files.el b/lisp/files.el
index 56d4679ad7..fa72e51c49 100644
--- b/lisp/files.el
+++ a/lisp/files.el
@@ -2657,6 +2657,13 @@
("\\.ltx\\'" . latex-mode)
("\\.dtx\\'" . doctex-mode)
("\\.org\\'" . org-mode)
+ ;; .dir-locals.el is not really elisp. Could use the
+ ;; `dir-locals-file' constant if it weren't defined below.
+ ("\\.dir-locals\\(-2\\)?\\.el\\'" . lisp-data-mode)
+ ("eww-bookmarks\\'" . lisp-data-mode)
+ ("tramp\\'" . lisp-data-mode)
+ ("places\\'" . lisp-data-mode)
+ ("\\.emacs-places\\'" . lisp-data-mode)
("\\.el\\'" . emacs-lisp-mode)
("Project\\.ede\\'" . emacs-lisp-mode)
("\\.\\(scm\\|stk\\|ss\\|sch\\)\\'" . scheme-mode)
diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index dbf2cb807b..0a99b8d6a3 100644
--- b/lisp/help-fns.el
+++ a/lisp/help-fns.el
@@ -1000,7 +1000,7 @@
(terpri)
(let ((buf (current-buffer)))
(with-temp-buffer
- (lisp-mode-variables nil)
+ (lisp-mode-variables)
(set-syntax-table emacs-lisp-mode-syntax-table)
(insert print-rep)
(pp-buffer)
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index a4544023f6..c83884fd25 100644
--- b/lisp/net/eww.el
+++ a/lisp/net/eww.el
@@ -1733,7 +1733,7 @@
(defun eww-write-bookmarks ()
(with-temp-file (expand-file-name "eww-bookmarks"
eww-bookmarks-directory)
- (insert ";; Auto-generated file; don't edit\n")
+ (insert ";; Auto-generated file; don't edit -*- mode: lisp-data -*-\n")
(pp eww-bookmarks (current-buffer))))
(defun eww-read-bookmarks ()
diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index cc22427e6d..2d36c5e257 100644
--- b/lisp/net/nsm.el
+++ a/lisp/net/nsm.el
@@ -964,6 +964,7 @@
(defun nsm-write-settings ()
(with-temp-file nsm-settings-file
+ (insert ";;;; -*- mode: lisp-data -*-\n")
(insert "(\n")
(dolist (setting nsm-permanent-host-settings)
(insert " ")
diff --git a/lisp/net/tramp-cache.el b/lisp/net/tramp-cache.el
index 6d87ce297b..09e30f000f 100644
--- b/lisp/net/tramp-cache.el
+++ a/lisp/net/tramp-cache.el
@@ -472,7 +472,7 @@
;; Dump it.
(with-temp-file tramp-persistency-file-name
(insert
- ";; -*- emacs-lisp -*-"
+ ";; -*- lisp-data -*-"
;; `time-stamp-string' might not exist in all Emacs flavors.
(condition-case nil
(progn
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 2f231781ba..f85fd771ca 100644
--- b/lisp/progmodes/elisp-mode.el
+++ a/lisp/progmodes/elisp-mode.el
@@ -250,7 +250,7 @@
map))
;;;###autoload
-(define-derived-mode emacs-lisp-mode prog-mode
+(define-derived-mode emacs-lisp-mode lisp-data-mode
`("ELisp"
(lexical-binding (:propertize "/l"
help-echo "Using lexical-binding mode")
@@ -268,35 +268,26 @@
\\{emacs-lisp-mode-map}"
:group 'lisp
(defvar project-vc-external-roots-function)
- (lisp-mode-variables nil nil 'elisp)
+ (setcar font-lock-defaults
+ '(lisp-el-font-lock-keywords
+ lisp-el-font-lock-keywords-1
+ lisp-el-font-lock-keywords-2))
+ (set-syntax-table emacs-lisp-mode-syntax-table)
(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-hook 'eldoc-documentation-functions
#'elisp-eldoc-documentation-function nil t)
(add-hook 'xref-backend-functions #'elisp--xref-backend nil t)
(setq-local project-vc-external-roots-function #'elisp-load-path-roots)
(add-hook 'completion-at-point-functions
#'elisp-completion-at-point nil 'local)
- ;; .dir-locals.el and lock files will 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 teaching elisp-mode about files that only hold data
- ;; structures, we disable the ELisp Flymake backend for these files.
- (unless
- (let* ((bfname (buffer-file-name))
- (fname (and (stringp bfname) (file-name-nondirectory
bfname))))
- (and (stringp fname)
- (or (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)))
+ (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil t)
+ (add-hook 'flymake-diagnostic-functions
+ #'elisp-flymake-byte-compile nil t))
;; Font-locking support.
diff --git a/lisp/progmodes/inf-lisp.el b/lisp/progmodes/inf-lisp.el
index fca803be18..9f34a377f4 100644
--- b/lisp/progmodes/inf-lisp.el
+++ a/lisp/progmodes/inf-lisp.el
@@ -274,7 +274,7 @@
to continue it."
(setq comint-prompt-regexp inferior-lisp-prompt)
(setq mode-line-process '(":%s"))
- (lisp-mode-variables t)
+ (lisp-mode-variables)
(setq comint-get-old-input (function lisp-get-old-input))
(setq comint-input-filter (function lisp-input-filter)))
diff --git a/lisp/saveplace.el b/lisp/saveplace.el
index f78639db24..fa0e181bb1 100644
--- b/lisp/saveplace.el
+++ a/lisp/saveplace.el
@@ -248,7 +248,7 @@
(delete-region (point-min) (point-max))
(when save-place-forget-unreadable-files
(save-place-forget-unreadable-files))
- (insert (format ";;; -*- coding: %s -*-\n"
+ (insert (format ";;; -*- coding: %s mode: lisp-data -*-\n"
(symbol-name coding-system-for-write)))
(let ((print-length nil)
(print-level nil))
On Sat, Apr 18, 2020 at 4:10 PM João Távora <joaotavora <at> gmail.com> wrote:
> On Sat, Apr 18, 2020 at 1:35 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > > > > > why not add it to auto-mod-alist?
> > > > > Anyway, I can surely switch to auto-mode-alist if you
> > > > > insist, no problem. Do you insist in this?
> > > > Do I have to insist?
> > > Any problem with doing so? I'll interpret that as a "Yes".
> > It's actually the other way around: if I don't feel my opinion is
> > strong enough, I usually say so.
>
> This is what actually-actually what happened: you asked "why
> not add it to auto-mod-alist? " I answered and asked if you
> insisted, because a question doesn't really sound imperative
> to me. If it was an instrument of rhetoric, it wasn't very effective.
>
> > > Anyway, I went and looked at the three files you mention, and
> > > I discovered they're not "fixed" as I thought. They're defcustom
> > > and defined way after auto-mode-alist, so we'd have to add-to-list,
> >
> > No need for such complexity. I meant to mention the standard names in
> > auto-mode-alist, under the assumption that many/most users don't
> > change the default names.
>
> OK.
>
> João
>
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 23:49:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 40573 <at> debbugs.gnu.org (full text, mbox):
>> Maybe "ELisp-Data" or more general "Lisp-Data".
>
> I meant the /d or /l suffix. I guess you are saying we shouldn't show
> that because it makes no sense?
Yes, fortunately with the new mode that will have the "Lisp-Data" lighter,
"/d" and "/l" suffixes are not needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sat, 18 Apr 2020 23:49:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> I've put "the code" in a branch in our repo, called
> 'scratch/add-lisp-data'.
Thanks. I noticed that you don't use semicolon between pairs:
;;; -*- coding: utf-8 mode: lisp-data -*-
I'm surprised that it still works, but wouldn't it be better to
follow the manual in (info "(emacs) Specifying File Variables")
and separate pairs with semicolon:
;;; -*- coding: utf-8; mode: lisp-data -*-
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 00:06:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 40573 <at> debbugs.gnu.org (full text, mbox):
On 19.04.2020 02:36, João Távora wrote:
> -(define-derived-mode lisp-mode prog-mode "Lisp"
> +(define-derived-mode lisp-mode lisp-data-mode "Lisp"
Speaking of. Is lisp-mode a special case of lisp-data-mode?
I would say maybe not: you usually can't (read) a whole Lisp buffer,
right? So I would make lisp-data-mode inherit from prog-mode (and have
them share a helper initializer).
But then again, I'm not sure which extra features a lisp-data-mode would
have, that would have to be incompatible with lisp-mode.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 00:21:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 40573 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
> On Sat, Apr 18, 2020 at 12:56 PM Basil L. Contovounesios <contovob <at> tcd.ie> wrote:
>
> gnus-adaptive-file-suffix, respectively. Would these suffixes be unique
> enough on their own to be added to auto-mode-alist? Perhaps
> gnus-score.el could do this after evaluating the defcustoms.
>
> auto-mode-alist has comments near it that discourage it.
Okay, but we could still statically add the default values to
auto-mode-alist, as was suggested elsewhere in this thread.
> I also think we have to understand that auto-mode-alist has the
> potential to introduce false positives. We don't want too many of
> those...
Indeed, hence my comment on whether "*.SCORE" files are sufficiently
unique.
> As for automatically adding a -*- mode -*- cookie - my guess is that
> gnus-score-save is the right place.
>
> Awesome, thanks. Well if you're confident about your guess. I think
> I've shown how easy it is to add them, so I'd personally feel free to
> submit a patch or to push to that branch (or to add a git commit
> and publish your branch somewhere else, if you don't have push
> permissions).
If no-one beats me to it, I'll submit a patch for the Gnus folks to
review after lisp-data-mode lands.
Thanks,
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 02:45:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> you want to add an emacs-lisp-data-mode in between lisp-data-mode
> and emacs-lisp-mode?
Not for now, no. We can add it later if the need arises,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 09:18:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 19, 2020 at 12:48 AM Juri Linkov <juri <at> linkov.net> wrote:
> > I've put "the code" in a branch in our repo, called
> > 'scratch/add-lisp-data'.
>
> Thanks. I noticed that you don't use semicolon between pairs:
>
> ;;; -*- coding: utf-8 mode: lisp-data -*-
>
> I'm surprised that it still works, but wouldn't it be better to
> follow the manual in (info "(emacs) Specifying File Variables")
> and separate pairs with semicolon:
>
> ;;; -*- coding: utf-8; mode: lisp-data -*-
>
Indeed, I didn't bother with the manual on this. I
did try with comma, it didn't work, then removed it
and didn't think twice. You're welcome to add them
as a commit to that branch if you want. And thanks
for clearing that mystery.
--
João Távora
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 09:26:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 19, 2020 at 1:05 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 19.04.2020 02:36, João Távora wrote:
> > -(define-derived-mode lisp-mode prog-mode "Lisp"
> > +(define-derived-mode lisp-mode lisp-data-mode "Lisp"
>
> Speaking of. Is lisp-mode a special case of lisp-data-mode?
>
> I would say maybe not: you usually can't (read) a whole Lisp buffer,
> right?
What do you mean? In what conditions? If anything it's more so
than in Emacs, because you can program CL's read-table and
make Lisp files look like JS, if you really want (but noone does that).
In that case lisp-data-mode would maybe break down a bit, but
so would lisp-mode itself since the syntax table wouldn't track those
changes (though It can take quite a beating, especially with
SLY/SLIME's enhancements). In that situation, you'd have to
use something like LSP, where the server constanty tell the
editor of the syntax of things. In all my years of CL, I've not
seen this a problem in practice.
So I would make lisp-data-mode inherit from prog-mode (and have
> them share a helper initializer).
>
If there is indeed a problem like this, then that's a solution yes.
Basically amounts to using composition instead of inheritance.
But I don't see it.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 11:42:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 19, 2020 at 1:20 AM Basil L. Contovounesios <contovob <at> tcd.ie>
wrote:
> João Távora <joaotavora <at> gmail.com> writes:
>
> > On Sat, Apr 18, 2020 at 12:56 PM Basil L. Contovounesios <
> contovob <at> tcd.ie> wrote:
> >
> > gnus-adaptive-file-suffix, respectively. Would these suffixes be unique
> > enough on their own to be added to auto-mode-alist? Perhaps
> > gnus-score.el could do this after evaluating the defcustoms.
> >
> > auto-mode-alist has comments near it that discourage it.
>
> Okay, but we could still statically add the default values to
> auto-mode-alist, as was suggested elsewhere in this thread.
>
Oh yes. At the time I didn't know that was an option,
but if you think it's "safe", go for it. If users change
defaults, they'll get false positives maybe. ¯\_(ツ)_/¯
> If no-one beats me to it, I'll submit a patch for the Gnus folks to
> review after lisp-data-mode lands.
Sounds good.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 13:59:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 40573 <at> debbugs.gnu.org (full text, mbox):
On 19.04.2020 12:25, João Távora wrote:
> On Sun, Apr 19, 2020 at 1:05 AM Dmitry Gutov <dgutov <at> yandex.ru
> <mailto:dgutov <at> yandex.ru>> wrote:
>
> On 19.04.2020 02:36, João Távora wrote:
> > -(define-derived-mode lisp-mode prog-mode "Lisp"
> > +(define-derived-mode lisp-mode lisp-data-mode "Lisp"
>
> Speaking of. Is lisp-mode a special case of lisp-data-mode?
>
> I would say maybe not: you usually can't (read) a whole Lisp buffer,
> right?
>
>
> What do you mean? In what conditions?
Just that you'd usually need to call 'read' multiple times, while
accumulating the intermediate results.
Whereas lisp-data files usually contain just one Lisp form. So e.g. any
"defun navigation" would jump between the direct children of that form.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 14:02:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sun, 19 Apr 2020 00:36:36 +0100
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> Here's the final patch as a sum of all the commits in the
> scratch/add-lisp-data-mode
> branch. I fixed the small lisp-mode-variables backward incompatibility
> issue.
Thanks for working on this.
> Any comments/objections?
I have one comment and one objection, below.
> Does this need documentation?
The new mode should be called out in NEWS, yes.
> diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
> index 13263f2fb5..3b0f5493ee 100644
> --- b/lisp/emacs-lisp/lisp-mode.el
> +++ a/lisp/emacs-lisp/lisp-mode.el
> @@ -611,15 +611,10 @@
> ;; a single docstring. Let's fix it here.
> (if (looking-at "\\s-+\"[^\n\"]+\"\\s-*$") ""))
>
> -(defun lisp-mode-variables (&optional lisp-syntax keywords-case-insensitive
> - elisp)
> +(defun lisp-mode-variables (&rest ignored)
Please don't make this backward-incompatible change. Let's keep the
API of this function unchanged.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 16:32:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 19, 2020, 14:57 Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> Whereas lisp-data files usually contain just one Lisp form.
That's a bad assumption. It just isn't true. And I don't see any difference
to elisp here, what did you have in mind?
So e.g. any
> "defun navigation" would jump between the direct children of that form.
>
There's no inherent structure to lisp data in general that supports any
kind of navigation, except maybe basic sexp navigation. There is nothing we
can parallelize to a defun. But if you know same subclass of lisp data that
does have some of those properties, we can a special major mode for it.
Doesn't have to be anything special, mind you, a couple of lines will
probably do what you might have in mind.
João
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 16:39:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 40573 <at> debbugs.gnu.org (full text, mbox):
On 19.04.2020 19:31, João Távora wrote:
> That's a bad assumption. It just isn't true.
Okay then. It just was a property of all the lisp-data files I'm aware
of. If that's not true for the general case, don't worry about it.
> And I don't see any
> difference to elisp here, what did you have in mind?
Elisp pretty much always has multiple forms on the top level.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Sun, 19 Apr 2020 20:19:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Apr 19, 2020 at 3:01 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Does this need documentation?
>
> The new mode should be called out in NEWS, yes.
>
Do you suggest any starting suggestion fpr phrasing?
I ask because you frequently find flaws in my
English.
> diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
> > index 13263f2fb5..3b0f5493ee 100644
> > --- b/lisp/emacs-lisp/lisp-mode.el
> > +++ a/lisp/emacs-lisp/lisp-mode.el
> > @@ -611,15 +611,10 @@
> > ;; a single docstring. Let's fix it here.
> > (if (looking-at "\\s-+\"[^\n\"]+\"\\s-*$") ""))
> >
> > -(defun lisp-mode-variables (&optional lisp-syntax
> keywords-case-insensitive
> > - elisp)
> > +(defun lisp-mode-variables (&rest ignored)
>
> Please don't make this backward-incompatible change. Let's keep the
> API of this function unchanged.
>
OK. See the latest commit.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 20 Apr 2020 13:42:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Sun, 19 Apr 2020 21:17:47 +0100
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> The new mode should be called out in NEWS, yes.
>
> Do you suggest any starting suggestion fpr phrasing?
Just that there's this new mode, and what files will (or should) turn
it on.
> I ask because you frequently find flaws in my
> English.
You make it sound like fixing the wording or changing it is some kind
of sin that you need to apologize. It isn't: I frequently find
phrases or wording in the documentation that could be improved, and
when I do, I fix them. Others fix what I wrote when they find similar
opportunities. This is routine, and says nothing bad about you or
your English. No one can excel in everything they do, and there's no
need to apologize or feel victimized when someone improves some text
you wrote.
> Please don't make this backward-incompatible change. Let's keep the
> API of this function unchanged.
>
> OK. See the latest commit.
LGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 20 Apr 2020 14:04:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 40573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Apr 20, 2020 at 2:41 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Do you suggest any starting suggestion fpr phrasing?
> > I ask because you frequently find flaws in my
> > English.
> You make it sound like fixing the wording or changing it is some kind
> of sin that you need to apologize.
No, I just asked you if you had any starting suggestion.
No need to read anything more into it, thank you. I'm
not apologizing for anything. My doc writing skills are
decent IMO, but Emacs has very specific style, is all.
> LGTM, thanks.
Shall I squash the commits and push to master?
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40573; Package
emacs.
(Mon, 20 Apr 2020 16:06:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 40573 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Mon, 20 Apr 2020 15:02:47 +0100
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
>
> Shall I squash the commits and push to master?
If there's nothing left to take care of, sure.
Reply sent
to
João Távora <joaotavora <at> gmail.com>:
You have taken responsibility.
(Fri, 01 May 2020 11:11:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
João Távora <joaotavora <at> gmail.com>:
bug acknowledged by developer.
(Fri, 01 May 2020 11:11:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 40573-done <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 20, 2020 at 5:05 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Mon, 20 Apr 2020 15:02:47 +0100
> > Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Juri Linkov <juri <at> linkov.net>, 40573 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
> >
> > Shall I squash the commits and push to master?
>
> If there's nothing left to take care of, sure.
Done. Also marking this bug "done".
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 29 May 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 344 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.