bug#46958: 28.0.50; invalid-function error for macros that have function bindings

[Robert Irelan]

I extracted the macros into a separate library `org-fc-macs` and then
called `(require 'org-fc-macs)` from the file where the error is
occurring `org-fc-type-normal.el`. This seems to have fixed the issue.

Now that I see that this has resolved the issue, I believe I can
understand why. It looks the byte compiler can deal well if it is
compiling a file where a function isn't defined by any of the
`require` calls in the file - as long as the function is defined at
runtime (which it would be with the way `org-fc` is written), you
won't run into any issues. On the other hand, the byte compiler needs
to have the definitions of all macros at hand during compile time, or
else it won't be able to expand them correctly:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Compiling-Macros.html.

In my case I'm using Doom Emacs, which uses the Straight package
manager. Straight has switched to byte compiling each package (along
with its explicit dependencies) in a separate process recently. When
this happened, `org-fc-type-normal.el` could no longer see the macro
definitions from `org-fc.el` at compile time, even though it could see
them at run time. Here's an explanation from the Doom Emacs package
maintainer: 
https://github.com/hlissner/doom-emacs/issues/4539#issuecomment-766307714.

Therefore, it looks like this is not a new bug in Emacs. It would be
nice if, when an invalid-function is thrown from bytecode, to check
the runtime environment to see a macro with the same name is defined,
and print a more informative error pointing out an issue with the
compilation.

On Sun, Mar 7, 2021 at 10:30 PM Phil Sainty <psainty@orcon.net.nz> wrote:
>
> On 8/03/21 10:38 am, Robert Irelan wrote:
> > No, that results in a circular import.
>
> I think a traditional way of dealing with this is to move the
> macro definitions to a separate library (e.g. fc-macs.el) and
> each library which uses the macros can then (require 'fc-macs)
>


-- 
Robert Irelan
rirelan@gmail.com