emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [RFC] Org document concept + document property drawers


From: Gustav Wikström
Subject: Re: [O] [RFC] Org document concept + document property drawers
Date: Sun, 1 Sep 2019 19:12:48 +0000

> From: Adam Porter

> Gustav Wikström <address@hidden> writes:
> 
> > 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.
 
I'd like very much to avoid this patch be pushed into a major version
update. Which leads me to think of your first suggestion to maybe
provide some backwards-compatibility for the parser. Specifically for
the insertion of the document-node in the syntax-tree. I'm not sure
how to go about that in a nice way though.

> 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.

I'm relying heavily on the test suite of org-mode for this, but I've
only made a few lines of changes inside ox.el and as far as I can see
no breakage at all for the respective built in exporters. Which leads
me to believe that if some external exports are built on the ox.el
core they'll have the same no-breakage behavior. Either that, or we
have holes to patch in our test suite.

Thanks again Adam for your comments!

Regards
Gustav



reply via email to

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