unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: "Braun Gábor" <braungb88@gmail.com>
Cc: 38694@debbugs.gnu.org
Subject: bug#38694: 26.1; update-*-autoloads fails with local generated-autoload-file
Date: Fri, 21 Aug 2020 14:01:53 +0200	[thread overview]
Message-ID: <87h7sw6wcu.fsf@gnus.org> (raw)
In-Reply-To: <2923979.zgHqgAkGFZ@gabor> ("Braun Gábor"'s message of "Fri, 20 Dec 2019 20:16:29 +0100")

Braun Gábor <braungb88@gmail.com> writes:

> Let the current directory have only the following two files:

[...]

> ;; Local Variables:
> ;; generated-autoload-file: "foo-autoloads.el"
> ;; End:

> M-x update-file-autoloads RET
> test-bar.el RET
> test-autoloads.el RET
>
> It produces an error message, which I copied from buffer *Messages*:
>
> autoload-generate-file-autoloads: DIRECTORY/test-bar.el:0:0: error: 
> wrong-type-argument: (stringp nil)

I can confirm this bug.

[...]

> IMHO, the root of the problem is that update-file-autoloads and
> update-directory-autoloads bind generated-autoload-file buffer locally
> (as it is a file local variable in test-foo.el) but intend to bind the
> default value.  Note that the docstrings of both functions
> mention the case of generated-autoload-file being buffer-local, so
> they ought to support this case.
>
> As the documented behaviour of these functions do not
> depend on the current buffer, I propose to simply switch to a
> temporary buffer so that the local settings don't interfere.
> This is a preemptive measure of other similar latent problems.
>
> Admittedly, creating a temporary buffer just to bind variables'
> default value seems to be wasteful, and I am very interested in
> learning a better, more idiomatic approach.

I don't think there is, and that's perhaps unfortunate.  What we have
here is a pretty unusual situation, though.

> +  ;; The temporary buffer is only to bind the default value of e.g.,
> +  ;; `generated-autoload-file'.  The current buffer is irrelevant.
> +  (with-temp-buffer
>    (let* ((generated-autoload-file (or outfile generated-autoload-file))

But I don't think this is the right way to fix this?  We want to heed
the buffer-local value of generated-autoload-file, and we want to bind
the global value of generated-autoload-file, I think?  Otherwise, what
would be the point of

> ;; Local Variables:
> ;; generated-autoload-file: "foo-autoloads.el"
> ;; End:

I'm not very familiar with this code, though, so I may be misreading it.

So the patch would be something like

+  (let ((autoload-file (or outfile generated-autoload-file)))
+    (with-temp-buffer
+      (let* ((generated-autoload-file autoload-file)

Or more complete (with indentation changes) below.

Does that makes sense?

diff --git a/lisp/emacs-lisp/autoload.el b/lisp/emacs-lisp/autoload.el
index 2eef451200..ad39f5642b 100644
--- a/lisp/emacs-lisp/autoload.el
+++ b/lisp/emacs-lisp/autoload.el
@@ -924,17 +924,20 @@ update-file-autoloads
   (interactive (list (read-file-name "Update autoloads for file: ")
 		     current-prefix-arg
 		     (read-file-name "Write autoload definitions to file: ")))
-  (let* ((generated-autoload-file (or outfile generated-autoload-file))
-	 (autoload-modified-buffers nil)
-	 ;; We need this only if the output file handles more than one input.
-	 ;; See https://debbugs.gnu.org/22213#38 and subsequent.
-	 (autoload-timestamps t)
-         (no-autoloads (autoload-generate-file-autoloads file)))
-    (if autoload-modified-buffers
-        (if save-after (autoload-save-buffers))
-      (if (called-interactively-p 'interactive)
-          (message "Autoload section for %s is up to date." file)))
-    (if no-autoloads file)))
+  (let ((autoload-file (or outfile generated-autoload-file)))
+    (with-temp-buffer
+      (let* ((generated-autoload-file autoload-file)
+	     (autoload-modified-buffers nil)
+	     ;; We need this only if the output file handles more than
+	     ;; one input.  See https://debbugs.gnu.org/22213#38 and
+	     ;; subsequent.
+	     (autoload-timestamps t)
+             (no-autoloads (autoload-generate-file-autoloads file)))
+        (if autoload-modified-buffers
+            (if save-after (autoload-save-buffers))
+          (if (called-interactively-p 'interactive)
+              (message "Autoload section for %s is up to date." file)))
+        (if no-autoloads file)))))
 
 (defun autoload-find-destination (file load-name)
   "Find the destination point of the current buffer's autoloads.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2020-08-21 12:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 19:16 bug#38694: 26.1; update-*-autoloads fails with local generated-autoload-file Braun Gábor
2020-08-21 12:01 ` Lars Ingebrigtsen [this message]
2020-10-02  2:37   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7sw6wcu.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=38694@debbugs.gnu.org \
    --cc=braungb88@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).