* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter @ 2019-11-05 20:58 Paul Pogonyshev 2020-09-05 0:30 ` Stefan Kangas 0 siblings, 1 reply; 11+ messages in thread From: Paul Pogonyshev @ 2019-11-05 20:58 UTC (permalink / raw) To: 38072 After (byte-compile-file "..." t) one normally expects that the file is loaded, all its functions and variables are visible etc. However, if file contains local variable `no-byte-compile', not only compilation is cancelled, `byte-compile-file' also doesn't load the file. Expected: if `byte-compile-file' cancels byte-compilation and `load' is non-nil, it should load the uncompiled source instead. Paul ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2019-11-05 20:58 bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter Paul Pogonyshev @ 2020-09-05 0:30 ` Stefan Kangas 2020-09-05 6:21 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Kangas @ 2020-09-05 0:30 UTC (permalink / raw) To: Paul Pogonyshev; +Cc: 38072 [-- Attachment #1: Type: text/plain, Size: 1516 bytes --] tags 38072 + patch thanks Paul Pogonyshev <pogonyshev@gmail.com> writes: > After (byte-compile-file "..." t) one normally expects that the file > is loaded, all its functions and variables are visible etc. However, > if file contains local variable `no-byte-compile', not only > compilation is cancelled, `byte-compile-file' also doesn't load the > file. > > Expected: if `byte-compile-file' cancels byte-compilation and `load' > is non-nil, it should load the uncompiled source instead. The fix is pretty simple (see attached), but I'm not sure what the correct behavior is here. The doc string of `byte-compile-file' says: Compile a file of Lisp code named FILENAME into a file of byte code. The output file’s name is generated by passing FILENAME to the function ‘byte-compile-dest-file’ (which see). With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling. ^^^^^^^^^^^^^^^ So should we load the file if we did not compile the file? I'm thinking yes, and I don't see what it could hurt to change it to load the file. If the user uses a prefix arg or the LOAD argument from Lisp, surely that was the intention. But on the other hand the text above seems deliberate, somehow? (And AFAICT the behavior has been not to load the file since pretty much forever, possibly since byte-compilation was first added.) Any other opinions here? Best regards, Stefan Kangas [-- Attachment #2: 0001-Ensure-byte-compile-file-loads-file-with-non-nil-loa.patch --] [-- Type: text/x-diff, Size: 1089 bytes --] From f48c2a446e5343f8ad104eb5523e834bb127825d Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Sat, 5 Sep 2020 02:14:54 +0200 Subject: [PATCH] Ensure byte-compile-file loads file with non-nil load arg * lisp/emacs-lisp/bytecomp.el (byte-compile-file): Load file when argument 'load' is non-nil, even if 'no-byte-compile' is also non-nil. (Bug#38072) --- lisp/emacs-lisp/bytecomp.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 966990bac9..d6db318e65 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -1970,6 +1970,9 @@ byte-compile-file (byte-compile-abbreviate-file target-file) (buffer-local-value 'no-byte-compile input-buffer)) (condition-case nil (delete-file target-file) (error nil))) + ;; Load the file even when not byte-compiling. (Bug#38072) + (when load + (load target-file)) ;; We successfully didn't compile this file. 'no-byte-compile) (when byte-compile-verbose -- 2.28.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-05 0:30 ` Stefan Kangas @ 2020-09-05 6:21 ` Eli Zaretskii 2020-09-05 15:26 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2020-09-05 6:21 UTC (permalink / raw) To: Stefan Kangas, Stefan Monnier; +Cc: pogonyshev, 38072 > From: Stefan Kangas <stefan@marxist.se> > Date: Sat, 5 Sep 2020 00:30:38 +0000 > Cc: 38072@debbugs.gnu.org > > Compile a file of Lisp code named FILENAME into a file of byte code. > The output file’s name is generated by passing FILENAME to the > function ‘byte-compile-dest-file’ (which see). > With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling. > ^^^^^^^^^^^^^^^ > > So should we load the file if we did not compile the file? I'm thinking > yes, and I don't see what it could hurt to change it to load the file. > If the user uses a prefix arg or the LOAD argument from Lisp, surely > that was the intention. > > But on the other hand the text above seems deliberate, somehow? (And > AFAICT the behavior has been not to load the file since pretty much > forever, possibly since byte-compilation was first added.) I'm indeed bothered by backward incompatibility of such a change. Paul expected the file to be loaded unconditionally, but how do we know someone else isn't expecting the opposite in this case? Also, do we want the same behavior in the interactive case? At the very least, if we decide to install this, the change in behavior should be in NEWS. Stefan, any comments on this? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-05 6:21 ` Eli Zaretskii @ 2020-09-05 15:26 ` Stefan Monnier 2020-09-07 16:37 ` Stefan Kangas 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2020-09-05 15:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Kangas, pogonyshev, 38072 >> Compile a file of Lisp code named FILENAME into a file of byte code. >> The output file’s name is generated by passing FILENAME to the >> function ‘byte-compile-dest-file’ (which see). >> With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling. >> ^^^^^^^^^^^^^^^ >> >> So should we load the file if we did not compile the file? I'm thinking >> yes, and I don't see what it could hurt to change it to load the file. >> If the user uses a prefix arg or the LOAD argument from Lisp, surely >> that was the intention. >> >> But on the other hand the text above seems deliberate, somehow? (And >> AFAICT the behavior has been not to load the file since pretty much >> forever, possibly since byte-compilation was first added.) > > I'm indeed bothered by backward incompatibility of such a change. > Paul expected the file to be loaded unconditionally, but how do we > know someone else isn't expecting the opposite in this case? Also, do > we want the same behavior in the interactive case? > > At the very least, if we decide to install this, the change in > behavior should be in NEWS. > > Stefan, any comments on this? FWIW, I find the "and load" feature to be a mistake: the function should return whether or not it successfully compiled the file, but shouldn't offer to load the result, since the callers can just as easily do it themselves (and then they can easily control what happens when compilation did not succeed). So, I'd suggest we deprecate that "feature" rather than try and decide which behavior is better. Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-05 15:26 ` Stefan Monnier @ 2020-09-07 16:37 ` Stefan Kangas 2020-09-07 16:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 11+ messages in thread From: Stefan Kangas @ 2020-09-07 16:37 UTC (permalink / raw) To: Stefan Monnier, Eli Zaretskii; +Cc: pogonyshev, 38072 Stefan Monnier <monnier@iro.umontreal.ca> writes: > FWIW, I find the "and load" feature to be a mistake: the function should > return whether or not it successfully compiled the file, but shouldn't > offer to load the result, since the callers can just as easily do > it themselves (and then they can easily control what happens when > compilation did not succeed). > So, I'd suggest we deprecate that "feature" rather than try and decide > which behavior is better. It's pretty convenient when running interactively though. I've tried using `C-u M-x byte-compile-file' (instead of my usual eval-buffer) for the last couple of days, and I kind of like getting both byte-compilation and load-file in one command. But if we do deprecate this, is there a better alternative that we can point users to? Should we just tell them to run two commands? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-07 16:37 ` Stefan Kangas @ 2020-09-07 16:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors 2020-09-13 13:06 ` Stefan Kangas 0 siblings, 1 reply; 11+ messages in thread From: Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-07 16:44 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, 38072, Stefan Monnier, pogonyshev Stefan Kangas <stefan@marxist.se> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> FWIW, I find the "and load" feature to be a mistake: the function should >> return whether or not it successfully compiled the file, but shouldn't >> offer to load the result, since the callers can just as easily do >> it themselves (and then they can easily control what happens when >> compilation did not succeed). >> So, I'd suggest we deprecate that "feature" rather than try and decide >> which behavior is better. > > It's pretty convenient when running interactively though. I've tried > using `C-u M-x byte-compile-file' (instead of my usual eval-buffer) for > the last couple of days, and I kind of like getting both > byte-compilation and load-file in one command. > > But if we do deprecate this, is there a better alternative that we can > point users to? Should we just tell them to run two commands? Hi Stefan, would having the load performed by `emacs-lisp-byte-compile-and-load' an option? Ciao Andrea ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-07 16:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-09-13 13:06 ` Stefan Kangas 2020-09-13 14:52 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Kangas @ 2020-09-13 13:06 UTC (permalink / raw) To: Andrea Corallo; +Cc: pogonyshev, Stefan Monnier, 38072 Andrea Corallo <akrl@sdf.org> writes: >>> FWIW, I find the "and load" feature to be a mistake: the function should >>> return whether or not it successfully compiled the file, but shouldn't >>> offer to load the result, since the callers can just as easily do >>> it themselves (and then they can easily control what happens when >>> compilation did not succeed). >>> So, I'd suggest we deprecate that "feature" rather than try and decide >>> which behavior is better. >> >> But if we do deprecate this, is there a better alternative that we can >> point users to? Should we just tell them to run two commands? > > would having the load performed by `emacs-lisp-byte-compile-and-load' an > option? Yes, that is good. I didn't know about that command. So I agree with Stefan M that the prefix argument should be deprecated. Do we have a process for that or should it just be removed? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-13 13:06 ` Stefan Kangas @ 2020-09-13 14:52 ` Eli Zaretskii 2020-09-21 22:30 ` Stefan Kangas 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2020-09-13 14:52 UTC (permalink / raw) To: Stefan Kangas; +Cc: akrl, pogonyshev, monnier, 38072 > From: Stefan Kangas <stefan@marxist.se> > Date: Sun, 13 Sep 2020 06:06:30 -0700 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, pogonyshev@gmail.com, > 38072@debbugs.gnu.org > > So I agree with Stefan M that the prefix argument should be deprecated. > Do we have a process for that or should it just be removed? We cannot just remove it. We should document that it's deprecated and use advertised-calling-convention to advertise the signature without it (which will also produce a warning about using the argument in some situations). ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-13 14:52 ` Eli Zaretskii @ 2020-09-21 22:30 ` Stefan Kangas 2020-09-22 2:28 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Stefan Kangas @ 2020-09-21 22:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38072, pogonyshev, monnier, akrl [-- Attachment #1: Type: text/plain, Size: 441 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> So I agree with Stefan M that the prefix argument should be deprecated. >> Do we have a process for that or should it just be removed? > > We cannot just remove it. We should document that it's deprecated and > use advertised-calling-convention to advertise the signature without > it (which will also produce a warning about using the argument in some > situations). How about the attached patch? [-- Attachment #2: 0001-byte-compile-file-Make-optional-LOAD-argument-obsole.patch --] [-- Type: text/x-diff, Size: 7646 bytes --] From 55df696bc3fd3401e50657173e627d2e1a4de6d1 Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefan@marxist.se> Date: Tue, 22 Sep 2020 00:16:22 +0200 Subject: [PATCH] byte-compile-file: Make optional LOAD argument obsolete * lisp/emacs-lisp/bytecomp.el (byte-compile-file): Declare optional LOAD argument obsolete. Adjust callers. (Bug#38072) (byte-recompile-file): Declare optional LOAD argument obsolete. * doc/lispref/compile.texi (Compilation Functions): Update documentation to reflect above obsoletion. * etc/NEWS: Announce above obsoletion. --- doc/lispref/compile.texi | 5 +---- etc/NEWS | 4 ++++ lisp/emacs-lisp/bytecomp.el | 17 +++++++++-------- lisp/org/org.el | 3 ++- lisp/progmodes/elisp-mode.el | 3 ++- lisp/speedbar.el | 2 +- test/lisp/emacs-lisp/bytecomp-tests.el | 7 ++++--- 7 files changed, 23 insertions(+), 18 deletions(-) diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi index e979fda41e..ad8afaae60 100644 --- a/doc/lispref/compile.texi +++ b/doc/lispref/compile.texi @@ -164,7 +164,7 @@ Compilation Functions in the current buffer after the form it has compiled. @end deffn -@deffn Command byte-compile-file filename &optional load +@deffn Command byte-compile-file filename This function compiles a file of Lisp code named @var{filename} into a file of byte-code. The output file's name is made by changing the @samp{.el} suffix into @samp{.elc}; if @var{filename} does not end in @@ -180,9 +180,6 @@ Compilation Functions This command returns @code{t} if there were no errors and @code{nil} otherwise. When called interactively, it prompts for the file name. -If @var{load} is non-@code{nil}, this command loads the compiled file -after compiling it. Interactively, @var{load} is the prefix argument. - @example @group $ ls -l push* diff --git a/etc/NEWS b/etc/NEWS index 6bfe45a683..5d9e6e7e2e 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1264,6 +1264,10 @@ since the latter uses 'M-s' as a prefix key of the search prefix map. ** 'vc-print-branch-log' shows the change log for BRANCH from its root directory instead of the default directory. +** `byte-compile-file' optional argument LOAD is now obsolete. +To load the file after byte-compiling, add a call to 'load' from Lisp +or use 'M-x emacs-lisp-byte-compile-and-load' interactively. + \f * Incompatible Lisp Changes in Emacs 28.1 diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 966990bac9..2968080afc 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -1822,7 +1822,7 @@ no-byte-compile \;; Local Variables:\n;; no-byte-compile: t\n;; End: ") ;Backslash for compile-main. ;;;###autoload(put 'no-byte-compile 'safe-local-variable 'booleanp) -(defun byte-recompile-file (filename &optional force arg load) +(defun byte-recompile-file (filename &optional force arg obsolete) "Recompile FILENAME file if it needs recompilation. This happens when its `.elc' file is older than itself. @@ -1836,10 +1836,9 @@ byte-recompile-file the input file even if the `.elc' file does not exist. Any other non-nil value of ARG means to ask the user. -If optional argument LOAD is non-nil, loads the file after compiling. - If compilation is needed, this functions returns the result of `byte-compile-file'; otherwise it returns `no-byte-compile'." + (declare (advertised-calling-convention (filename &optional force arg) "28.1")) (interactive (let ((file buffer-file-name) (file-name nil) @@ -1868,8 +1867,10 @@ byte-recompile-file (progn (if (and noninteractive (not byte-compile-verbose)) (message "Compiling %s..." filename)) - (byte-compile-file filename load)) - (when load + (byte-compile-file filename) + (when obsolete + (load (if (file-exists-p dest) dest filename)))) + (when obsolete (load (if (file-exists-p dest) dest filename))) 'no-byte-compile))) @@ -1877,12 +1878,12 @@ byte-compile-level "Depth of a recursive byte compilation.") ;;;###autoload -(defun byte-compile-file (filename &optional load) +(defun byte-compile-file (filename &optional obsolete) "Compile a file of Lisp code named FILENAME into a file of byte code. The output file's name is generated by passing FILENAME to the function `byte-compile-dest-file' (which see). -With prefix arg (noninteractively: 2nd arg), LOAD the file after compiling. The value is non-nil if there were no errors, nil if errors." + (declare (advertised-calling-convention (filename) "28.1")) ;; (interactive "fByte compile file: \nP") (interactive (let ((file buffer-file-name) @@ -2035,7 +2036,7 @@ byte-compile-file filename)))) (save-excursion (display-call-tree filename))) - (if load + (if obsolete (load target-file)) t)))) diff --git a/lisp/org/org.el b/lisp/org/org.el index f1a7f61a9a..3c2df4e31e 100644 --- a/lisp/org/org.el +++ b/lisp/org/org.el @@ -223,7 +223,8 @@ org-babel-load-file (org-babel-tangle-file file tangled-file "emacs-lisp")) (if compile (progn - (byte-compile-file tangled-file 'load) + (byte-compile-file tangled-file) + (load tangled-file) (message "Compiled and loaded %s" tangled-file)) (load-file tangled-file) (message "Loaded %s" tangled-file)))) diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index b4803687b5..f5f39f76a3 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -196,7 +196,8 @@ emacs-lisp-byte-compile-and-load (if (and (buffer-modified-p) (y-or-n-p (format "Save buffer %s first? " (buffer-name)))) (save-buffer)) - (byte-recompile-file buffer-file-name nil 0 t)) + (byte-recompile-file buffer-file-name nil 0) + (load buffer-file-name)) (defun emacs-lisp-macroexpand () "Macroexpand the form after point. diff --git a/lisp/speedbar.el b/lisp/speedbar.el index aab6a3a128..9c5f028e4a 100644 --- a/lisp/speedbar.el +++ b/lisp/speedbar.el @@ -1392,7 +1392,7 @@ speedbar-item-byte-compile (if (and (file-exists-p f) (string-match "\\.el\\'" f)) (progn (dframe-select-attached-frame speedbar-frame) - (byte-compile-file f nil) + (byte-compile-file f) (select-frame sf) (speedbar-reset-scanners))) )) diff --git a/test/lisp/emacs-lisp/bytecomp-tests.el b/test/lisp/emacs-lisp/bytecomp-tests.el index a9dcf15261..ea5aacd791 100644 --- a/test/lisp/emacs-lisp/bytecomp-tests.el +++ b/test/lisp/emacs-lisp/bytecomp-tests.el @@ -444,8 +444,8 @@ test-byte-comp-compile-and-load (if compile (let ((byte-compile-dest-file-function (lambda (e) elcfile))) - (byte-compile-file elfile t)) - (load elfile nil 'nomessage))) + (byte-compile-file elfile))) + (load elfile nil 'nomessage)) (when elfile (delete-file elfile)) (when elcfile (delete-file elcfile))))) (put 'test-byte-comp-compile-and-load 'lisp-indent-function 1) @@ -646,7 +646,8 @@ bytecomp-tests-function-put (setq bytecomp-tests--foobar (bytecomp-tests--foobar)))) (print form (current-buffer))) (write-region (point-min) (point-max) source nil 'silent) - (byte-compile-file source t) + (byte-compile-file source) + (load source) (should (equal bytecomp-tests--foobar (cons 1 2))))) (ert-deftest bytecomp-tests--test-no-warnings-with-advice () -- 2.28.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-21 22:30 ` Stefan Kangas @ 2020-09-22 2:28 ` Eli Zaretskii 2020-10-20 16:56 ` Stefan Kangas 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2020-09-22 2:28 UTC (permalink / raw) To: Stefan Kangas; +Cc: 38072, pogonyshev, monnier, akrl > From: Stefan Kangas <stefan@marxist.se> > Date: Mon, 21 Sep 2020 22:30:30 +0000 > Cc: 38072@debbugs.gnu.org, pogonyshev@gmail.com, monnier@iro.umontreal.ca, > akrl@sdf.org > > > We cannot just remove it. We should document that it's deprecated and > > use advertised-calling-convention to advertise the signature without > > it (which will also produce a warning about using the argument in some > > situations). > > How about the attached patch? OK, but I'd prefer not to rename the argument itself, as that would get in the way of understanding the code. Thanks. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter 2020-09-22 2:28 ` Eli Zaretskii @ 2020-10-20 16:56 ` Stefan Kangas 0 siblings, 0 replies; 11+ messages in thread From: Stefan Kangas @ 2020-10-20 16:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38072, pogonyshev, monnier, akrl close 38072 28.1 thanks Eli Zaretskii <eliz@gnu.org> writes: >> > We cannot just remove it. We should document that it's deprecated and >> > use advertised-calling-convention to advertise the signature without >> > it (which will also produce a warning about using the argument in some >> > situations). >> >> How about the attached patch? > > OK, but I'd prefer not to rename the argument itself, as that would > get in the way of understanding the code. Thanks, so I fixed that and pushed to master as commit 4a575eb18c. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-10-20 16:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-05 20:58 bug#38072: when `byte-compile-file' finds out that a file is `no-byte-compile', it ignores `load' parameter Paul Pogonyshev 2020-09-05 0:30 ` Stefan Kangas 2020-09-05 6:21 ` Eli Zaretskii 2020-09-05 15:26 ` Stefan Monnier 2020-09-07 16:37 ` Stefan Kangas 2020-09-07 16:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors 2020-09-13 13:06 ` Stefan Kangas 2020-09-13 14:52 ` Eli Zaretskii 2020-09-21 22:30 ` Stefan Kangas 2020-09-22 2:28 ` Eli Zaretskii 2020-10-20 16:56 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).