* 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).