[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-fun
From: |
Alan Mackenzie |
Subject: |
bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) |
Date: |
Tue, 10 May 2022 10:32:40 +0000 |
Hello, Bob.
On Sun, May 08, 2022 at 15:29:12 -0400, Bob Rogers wrote:
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> cairo version 1.16.0)
> of 2022-05-08 built on orion
> Repository revision: 278b18a460caf34e422847d10ac3f0b62bef4996
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
> System Description: openSUSE Leap 15.3
> The problem occurs with an evaluated "interactive" form in a defun
> that is compiled with compile-defun -- and it may have escaped notice
> until now because it doesn't seem to happen if the source is part of
> Emacs (i.e. is compiled in a file that git knows about).
> 1. emacs -Q
> 2. Find an elisp file with an interactive form that does not belong
> to an Emacs working copy. I used the align-highlight-rule snippet
> below, copied from lisp/align.el.
> 3. Evaluate the first two forms, and do "M-x compile-defun" to
> compile the third.
> 4. Attempt to invoke the command via "M-x align-highlight-rule RET".
> What you should see then is a backtrace that starts something like this:
> Debugger entered--Lisp error: (invalid-function #<symbol list at 476>)
> (#<symbol list at 476> (#<symbol region-beginning at 482>) ...)
> call-interactively(align-highlight-rule record nil)
> command-execute(align-highlight-rule record)
> Disassembly shows that the interactive form is not compiled, and the
> arglist is full of #<symbol X at Y>:
> byte code for align-highlight-rule:
> doc: Highlight the whitespace which a given rule would have
> modified. ...
> args: (#<symbol beg at 49> #<symbol end at 53> #<symbol title at 57>
> ...)
> interactive: (#<symbol list at 476> (#<symbol region-beginning at
> 482>) ...)
> 0 constant intern
> 1 varref title
> 2 call 1
> 3 varref align-mode-exclude-rules-list
> Disassembling the in-tree version, whether from "M-x compile-defun" or
> file compilation, shows neither of these problems (go figure).
Thanks for taking the trouble to report this bug. I can reproduce it
here. At a guess, the critical detail is having align-highlight-rule
in a different file's buffer on doing M-x compile-defun.
> And of course "M-x eval-defun" and "M-x byte-compile-file" continue
> to DTRT, so I am not in any hurry for a fix. TIA,
I hope to be able to fix this within a few days.
> -- Bob Rogers
> http://www.rgrjr.com/
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).