Re: Permanently fix org versioning breakage during builds?

[T.V Raman]

And while I remember, we also need to investigate how badly these
breakages bite native-compile; I'm not enabling native-compile for
various other reasons, so am  not in a position to verify,


João Távora writes:
 > On Sun, Dec 24, 2023 at 5:13 PM Ihor Radchenko <yantar92@posteo.net> wrote:
 > 
 > > It is not about a specific macro. Any macro may be broken this way.
 > 
 > No, that's that not true.  Only macros defined in one file and
 > expanded in other files.  And not if you use this technique.
 > 
 > My advice is to find a list of macros defined in one file and
 > expanded in another file.
 > 
 > > There may be confusion about `org-assert-version' macro vs. all other
 > > macros. The former is my attempt to detect potential breakage of the
 > > latter.
 > >
 > > > [  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.
 > 
 > > > Anyway, let's apply the "CALL-WITH" technique:
 > > >
 > > > (cl-defmacro org-export-with-buffer-copy ( &rest body
 > > >                                            &key to-buffer drop-visibility
 > > >                                            drop-narrowing drop-contents
 > > >                                            drop-locals
 > > >                                            &allow-other-keys)
 > > >   "..."
 > > >   `(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.
 > 
 > > in Emacs tree - Emacs has only stable version. Your patch will not apply
 > > on the latest Org main branch.
 > 
 > Surely can't be very hard to adapt it now that I've shown how it's done,
 > it's a localized change to a single definition in a single file.
 > 
 > João

--