Re: Permanently fix org versioning breakage during builds?

[Ihor Radchenko]

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

> (benchmark-run-compiled 100000 (joaot/funcall (with-temp-buffer)))
> ;;(1.4344190810000002 179 1.223486917999999)
> ;;(1.418460156 179 1.211255973)
> ;;(1.449469906 179 1.232802902000003)
> ;;(1.419341703 179 1.2082177509999994)
> ;;(1.517436337 179 1.2952383430000012)
>
> The time is completely dominated by allocation and
> garbage collection.

> A single cons allocation per macroexpansion is enough
> to make the difference unmeasurable.  In fact, to be able
> to measure it, you'll have to make body completely empty
> and run it tens of milions of iterations to be able to measure
> anything perceivable in the tenths of a second.

I now tried to change `org-with-wide-buffer' to use funcall and I now
agree with you that performance degradation is not visible.

>> - 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.
>
> It doesn't have a solution! It's just what macros give you: syntax
> manipulation in exchange for late binding. You must add functions
> back to regain Lisp's late binding and deal with Lisp's build systems
> which don't usually let you specify dependencies between files.

By "non-trivial to solve" I meant that solving it would require
introducing dependencies between files.

>> - 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.
>
> I've already explained that is a different other for people who use ELPA
> & git to track bleeding edge.  It has another solution.  It's very confusing
> to see you reject a solution to a given real problem just because it
> doesn't solve another completely different one.

That's not what I meant. What I meant is that Org mode solving stale
macro problem in Org code will not fix broken Emacs builds - they can
still be broken because of other macros elsewhere in Emacs tree.
And Emacs maintainers told me that there is no plan to address stale
macros issue in Emacs tree - users are expected to run make bootstrap or
similar commands in case of breakage.

So, unless there is some _additional_ benefit for Org mode, I see no
point spending my time to solve stale macro problem just in Org mode.

Such additional benefit could be solving the mixed version problem, but,
unfortunately, mixed version problem is not about macros.

>> - 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.
>
> So you'd rather bother everyone else with broken builds...

If Emacs maintainers say that it is ok, I do not see why I should try to
solve it just for Org mode.

> And what maintenance burden.  It's much easier to write macros
> like this.  No hygiene concerns, no awkward ',foo' everywhere.

What you described is not how Elisp manual suggest to write macros and
not what people usually submit in patches. If I decide to follow your
suggestion, we will need to maintain an extra rule about macro style - I
(and other Org mode maintainers) will have to watch for this yet another
extra thing. Hence maintenance burden.

>> - And that maintenance burden also comes with an additional downside of
>>   potential performance degradation.
>
> This bullet is a repeat / filler. Fallacious argument with no data.  I've 
> given
> you hard data. Read it.

I agree that this argument is incorrect.

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