Re: Permanently fix org versioning breakage during builds?

[Ihor Radchenko <yantar92@posteo.net>]

João Távora <joaotavora@gmail.com> writes:

>> 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.

I doubt that you are right about 99.9%, because I know that we have some
macros (like `org-with-wide-buffer') that are utilized in
performance-critical code - org-element-cache.

And it is not the only concern why I do not feel that your suggestion is
a good idea:

- The problem with stale macros is not just Org mode's problem - it is
  the problem with Elisp compiler machinery. A very hard one that is
  non-trivial to solve.

- The rest of Emacs just leaves the problem with macros as is and the
  only reason why Org mode touched it is that it was simply a side
  effect of how org-assert-version is implemented - it is first and
  foremost aiming at handling the issue with multiple Org mode versions
  being loaded at the same time, while the side effect of detecting
  stale macros was a bonus.

- Even if I solve the problem with macros using the technique you
  proposed, the problem with mixed versions still has to be handled.

- Further, fixing the stale macro problem means rewriting all the
  existing, and, more importantly, future Org mode macros - an extra
  maintenance burden which I am very hesitant to take.

- And that maintenance burden also comes with an additional downside of
  potential performance degradation.

So, all-in-all, I do not see the idea with wrapped macros as something
practical for Org mode.

For now, I will go ahead and disable org-assert-version checks when
compiling Org mode within Emacs tree, leaving it enabled when Org is
installed by other means.

This will have a downside of missing detecting mixed versions when ELPA
version of Org mode is loaded first, followed (somehow) by built-in Org
version. But I think that such scenario is uncommon enough - one would
have to delete newer Org mode from load-path, which would be a call for
trouble anyway.

I also hope to find a more robust approach for org-assert-version that
will not annoy users with warnings/errors.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>