From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: Michael Brand <michael.ch.brand@gmail.com>,
Org Mode <emacs-orgmode@gnu.org>
Subject: Re: link interfering with brackets when abbreviated
Date: Wed, 26 Feb 2014 22:15:53 +0100 [thread overview]
Message-ID: <87y50xr2wm.fsf@gmail.com> (raw)
In-Reply-To: <87bnxtixdz.fsf@bzg.ath.cx> (Bastien's message of "Wed, 26 Feb 2014 18:42:16 +0100")
Bastien <bzg@gnu.org> 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
next prev parent reply other threads:[~2014-02-26 21:15 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 12:11 link interfering with brackets when abbreviated Michael Brand
2014-02-26 15:10 ` Michael Brand
2014-02-26 15:25 ` Nicolas Goaziou
2014-02-26 15:44 ` Michael Brand
2014-02-26 15:54 ` Nicolas Goaziou
2014-02-26 16:22 ` Michael Brand
2014-02-26 16:41 ` Nicolas Goaziou
2014-02-26 17:03 ` Michael Brand
2014-02-26 17:20 ` Bastien
2014-02-26 19:02 ` Nicolas Goaziou
2014-02-26 22:54 ` Bastien
2014-02-27 10:28 ` Nicolas Goaziou
2014-02-27 11:04 ` Bastien
2014-02-27 20:01 ` Michael Brand
2014-02-27 22:08 ` Bastien
2014-02-27 23:43 ` Nicolas Goaziou
2014-03-01 18:44 ` Yasushi SHOJI
2014-03-01 20:20 ` Nicolas Goaziou
2014-03-01 20:54 ` Bastien
2014-03-01 20:57 ` Bastien
2014-03-01 21:35 ` Nicolas Goaziou
2014-03-01 21:50 ` Bastien
2014-03-01 22:14 ` Nicolas Goaziou
2014-03-02 13:35 ` Bastien
2014-03-03 14:12 ` Matt Lundin
2014-03-02 0:22 ` Yasushi SHOJI
2014-03-02 9:05 ` Nicolas Goaziou
2014-03-02 13:22 ` Bastien
2014-03-02 14:27 ` Nicolas Goaziou
2014-03-02 15:49 ` Bastien
2014-03-02 16:32 ` Thorsten Jolitz
2014-03-03 3:41 ` Josiah Schwab
2014-03-03 5:54 ` Michael Brand
2014-03-03 9:50 ` Context of interaction vs. literal syntactic interpretation (was: link interfering with brackets when abbreviated) Bastien
2014-03-03 16:09 ` Context of interaction vs. literal syntactic interpretation Matt Lundin
2014-03-03 18:00 ` Nick Dokos
2014-03-03 18:13 ` Jonathan Leech-Pepin
2014-03-14 13:46 ` Sebastien Vauban
2014-03-21 8:44 ` Bastien
2014-03-21 13:17 ` Nicolas Goaziou
2014-03-23 22:51 ` Bastien
2014-03-24 13:12 ` Nicolas Goaziou
2014-03-01 18:44 ` link interfering with brackets when abbreviated Yasushi SHOJI
2014-02-26 17:42 ` Bastien
2014-02-26 21:15 ` Nicolas Goaziou [this message]
2014-02-26 22:21 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2014-03-02 21:16 Gustav Wikström
2014-03-03 1:30 ` Ista Zahn
2014-03-03 19:33 ` Samuel Wales
2014-03-03 19:46 ` Samuel Wales
2014-03-03 22:18 ` Sebastien Vauban
2014-03-03 22:33 ` Samuel Wales
[not found] ` <CAJcAo8vh0F0tqgX4=gUhJoWFcAsTiwfyi7Fp=spQeoaBog1OMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-04 12:16 ` Sebastien Vauban
2014-03-04 20:06 ` Samuel Wales
2014-03-19 11:19 ` Bastien
2014-03-03 10:58 ` Christian Moe
2014-03-03 16:11 ` Sebastien Vauban
2014-03-03 23:16 ` Robert Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y50xr2wm.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).