Re: Permanently fix org versioning breakage during builds?

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

On Sun, Dec 24, 2023 at 6:10 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> João Távora <joaotavora@gmail.com> writes:

> >> > [  Tangent: one thing I notice is that the expansion in ox-html.el is
> >> > buggy.  It evaluates the keyword arguments to the macros multiple
times
> >> > for no effect.  The solution would be to change the macro calling
> >> > convention to be:
> >> >
> >> > (cl-defmacro org-export-with-buffer-copy ((&key to-buffer
drop-visibility
> >> >                                           drop-narrowing
drop-contents
> >> >                                           drop-locals
> >> >                                           &allow-other-keys) &body
body)
> >> >   ...)
> >>
> >> May you elaborate?
> >
> > Just expand the macro as in ox-html.el and see for yourself.
>
> Hmm... It actually looks like a problem with `cl-defmacro' rather than
> with macro definition itself.

No, Common Lisp's DEFMACRO works exactly like this. You need to understand
how &rest works with &key and &allow-other-keys. It _also_ keeps the keys.
That's just how it works.

> >> >   `(org-export--call-with-buffer-copy (lambda () ,@body)
> >>
> >> AFAIU, this technique will prevent compiler optimizations, won't it?
> >
> > What compiler optimizations are you talking about?  The only
> > price to pay is an extra funcall.  "We can solve any problem by
> > introducing an extra level of indirection."  The function compiled,
> > where presumably the complicated optimization-worthy logic lies
> > is still compiled.
>
> Any use of (funcall 'symbol ...) means that compiler is not able to know
> the function slot of 'symbol at compile time, because it may change.
> Hence, any optimization that relies upon knowing both the context of the
> funcall and the internals of 'symbol will become impossible.

It's not even a symbol that is in question. And whatever this
function-calling, it is more than probably dwarved by the cost of the
remaining macro expansion. If you were making, say, a sequence processing
library it would have to be measured. But here I'm 99.9% sure there's no
efficiency downside. Just in allocation costs alone, your macro creates
buffers, copies things, etc and then there's the expanded body. Just fixing
the bug I've found will more than pay for it likely.

> And this will not solve the problem when Org files are loaded in mixture
> from Emacs built-in version and from some other version (ELPA, manually
> installed Org mode, etc).

That is a different problem with a different solution, and it only affects
those who update Org from ELPA. There are many problems in the world, you
can't expect a single solution to fix them all. That other problem, for
example, has nothing to do with macro expansion site recompilation. I'm
only targeting _that_ one for now, because that is what directly affects
developers or anyone working with an Emacs from master.

João

[-- Attachment #2: Type: text/html, Size: 3892 bytes --]