From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Org document concept + document property drawers
Date: Sun, 01 Sep 2019 11:26:42 -0500 [thread overview]
Message-ID: <87h85wj83h.fsf@alphapapa.net> (raw)
In-Reply-To: HE1PR02MB3033F47A9890C26027AED2A0DABF0@HE1PR02MB3033.eurprd02.prod.outlook.com
Gustav Wikström <gustav@whil.se> writes:
Hi Gustav,
Thanks for your reply. I sent my most recent message, which reiterated
my question, before this message of yours came through.
>> This is a very interesting idea, and I don't want to dismiss your work,
>> but I am concerned about how much third-party code will likely break by
>> changing the results returned by org-element for parsing an Org buffer.
>> I haven't thoroughly studied all of the code in your patches, so I may
>> be wrong, but I think the breakage could be extensive. For example,
>> simple operations like destructuring the results of org-element parsing
>> functions may be broken. Have you done any investigation into this
>> issue?
>>
>> Maybe there should be a transitional period in which the existing
>> org-element parsing functions would work as before, and the new
>> document-level elements would be returned by a new org-element
>> document-level parsing function. Frankly, if there is breakage,the
>> transition would probably take a few years, because there is a lot of
>> code out there that has worked for years and may not be updated or
>> replaced for years.
>
> I have not investigated much into that to be honest. I'd argue that
> it's a fairly trivial change in terms of the parser though. Everything
> will work as before except when you're after the whole buffer
> syntax-tree. In that case one will have to dig one step deeper into
> the tree to find the content.
>
> Previous tree:
> (org-data nil CONTENTS)
>
> With this patch:
> (org-data nil (document (doc-props) CONTENTS))
>
> Yeah.. The structure changed a bit. But it's a fairly trivial change
> in my opinion. Everything else works as before AFAIK... But I might be
> overseeing something. Please enlighten me in that case!
Thanks, that's a helpful illustration of the difference.
I'm glad that it only changes the result of parsing entire buffers.
That will limit the breakage.
However, there is code in the wild that does parse entire buffers that
way. So that will break some code. At least the necessary changes
would be minor.
However, if it does indeed precipitate a major Org version increment,
then such code will likely need to maintain compatibility with
older code for some time, because, like Emacs, Org versions tend to
stick around for a while.
Another question: how does this patch affect org-export backends? I've
only a passing familiarity with them. I'm guessing that some may break,
some of which may live outside of the Org repo. It might be a good idea
to take a look at some of the ones on MELPA to see if they would be
affected.
next prev parent reply other threads:[~2019-09-01 16:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-01 16:08 [RFC] Org document concept + document property drawers Gustav Wikström
2019-09-01 16:26 ` Adam Porter [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-01 19:17 Gustav Wikström
2019-09-01 19:12 Gustav Wikström
2019-09-01 18:51 Gustav Wikström
2019-08-31 18:49 Gustav Wikström
2019-09-01 5:20 ` Adam Porter
2019-09-01 10:38 ` Nicolas Goaziou
2019-09-01 14:41 ` Gustav Wikström
2019-09-06 20:09 ` Nicolas Goaziou
2019-09-29 9:39 ` Gustav Wikström
2019-09-01 15:25 ` Gustav Wikström
2019-09-01 16:11 ` Adam Porter
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=87h85wj83h.fsf@alphapapa.net \
--to=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
/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).