[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] link interfering with brackets when abbreviated

From: Nicolas Goaziou
Subject: Re: [O] link interfering with brackets when abbreviated
Date: Wed, 26 Feb 2014 22:15:53 +0100

Bastien <address@hidden> writes:

> Here are the reasons why we *want* to rewrite some functions using
> org-element:

I don't know who "we" is. Apparently, I'm not in.

> - *bug fixing*: the rewrite fixes bugs.
> - *speed*: the rewrite provides a faster implementation;
> - *predictability*: the rewrite provides a more predictable
>    implementation;
> - *completeness*: the rewrite covers more use-cases than the
>   previous /ad hoc/ implementation.
> Now here are the reasons why we *don't want* to use org-element:
> - *high ceiling*: if the rewrite is less readable for potential
>   developers.
> - *complexity*: if the rewritten version is more complex.
> - *rigidity*: if the rewritten version adds unwanted constraints.
> Of course, the decision is always a trade-off.
> I'm particularily sensitive to the "high ceiling" point above: we
> don't want all contributors to learn about Org elements before they
> can submit a patch -- of course, many will do, and we can encourage
> them to do so, but let's not close too many doors.
> IOW, even though org-element.el is great (and I hope my comments above
> will not be taken as criticism), "rewriting using org-element" is not
> a goal /per se/, just one great possibility to use when needed.

I think at least one of us is missing the point. I do not "rewrite using
Elements" for any of the reasons above. But before I explain my reasons,
I will comment "we"'s a bit.

I cannot talk about bug fixing and completeness as it depends on the
function rewritten. Though, don't hold your breath, implementation with
Elements will /always/ be slower than the current one. I'm working on
the cache to make that fact bearable, but I don't possess pixie dust.
Also, I'm pretty sure it will never be less rigid. A parser is
inherently very rigid. But this will sure make it more predictable.

Moreover, learning about "org-element.el" is not that hard. There are
4 major functions: `org-element-at-point', `org-element-context',
`org-element-property' and `org-element-type'. Of course, it can help to
also know about properties attached to each element type. That's
documented in Worg and pretty explicit in "org-element.el".

Anyway, back to my reasons to "rewrite using Elements".

Org consists of mostly (but not totally) independent parts, each one
implementing its own Org parser, similar to the others, but sometimes
slightly different. This is, to say the least, highly inefficient. It is
also a potential source of bugs.

Worse, it can impede further improvements. Indeed, I doubt that anyone
knows Org's full code base. So any slight change to syntax could break
some unknown parts of Org. Therefore, basically no structural
improvement can happen today without tremendous efforts and pain (for
the very same reasons, no new export back-end could be created

A function rewritten using Elements shares the same knowledge about Org
syntax with other rewritten functions. If we improve Elements, all of
them benefit from the improvement. If we modify it, all of them get the
modification. I'm exaggerating it a bit, but I'm sure you get the idea.
It is no panacea, but IMO, Org will be a better place when all of its
parts agree on a common, unambiguous, syntax.

So, in a nutshell, rewriting using org-element is almost a goal /per
se/. It comes with a price, which is that a re-implementation is not
a perfect copy of the original function, but the reward is higher. If
"we" disagree with that, then it would nice be if "we" could let me
know. Better late than sorry, I guess.


Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]