From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: link interfering with brackets when abbreviated Date: Wed, 26 Feb 2014 22:15:53 +0100 Message-ID: <87y50xr2wm.fsf@gmail.com> References: <87bnxtixdz.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIlpJ-0002jK-JO for emacs-orgmode@gnu.org; Wed, 26 Feb 2014 16:15:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIlpE-0007Zp-6S for emacs-orgmode@gnu.org; Wed, 26 Feb 2014 16:15:37 -0500 In-Reply-To: <87bnxtixdz.fsf@bzg.ath.cx> (Bastien's message of "Wed, 26 Feb 2014 18:42:16 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: Michael Brand , Org Mode Bastien 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 yesterday). 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. Regards, -- Nicolas Goaziou