Hi Timothy,
Timothy writes:
> It’s not the choice I’d make, but what matters more is that I now better
> appreciate/understand the motivation for leaving those bit in.
well, this is always a trade-off: we try to stick to a "users' first*"
principle, while managing the burden for maintainers. I
Hi Bastien,
> Org is made of many areas and partial backward-compatibility can
> still be useful. When people report compatibility problems with
> Emacs <26, we can guide them so that they enhance org-compat.el.
>
> It is not because we don’t promise compatibility for Emacs < 26
> that we should
Hi Timothy,
Timothy writes:
> Personally I’m more inclined towards an all-or-nothing approach.
I understand this inclination but I disagree.
Org is made of many areas and partial backward-compatibility can
still be useful. When people report compatibility problems with
Emacs <26, we can guide
Hi Bastien,
>> I’m tempted to make some patches to remove all the Emacs < 26
>> compatibility code if we no longer need it. What do you think?
>
> We should NOT remove this code: many people probably use/need it.
>
> Anything that helps keeping Org compatible with Emacs < 26 is
> still useful, th
Hi Timothy,
Timothy writes:
> I’m tempted to make some patches to remove all the Emacs < 26
> compatibility code if we no longer need it. What do you think?
We should NOT remove this code: many people probably use/need it.
Anything that helps keeping Org compatible with Emacs < 26 is
still us
Hi Bastien,
> Our commitment is that the latest Org version is compatible with the
> last three stable versions of Emacs.
>
> So when Emacs 28 and Org 9.6 are both out, we guarantee that Org is
> compatible with Emacs 28, 27 and 26.
>
> Does that explain it better?
Thanks for clarifying. That’s p
