From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: [RFC] Org document concept + document property drawers Date: Sun, 01 Sep 2019 11:26:42 -0500 Message-ID: <87h85wj83h.fsf@alphapapa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55690) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4Sgm-0004oh-V1 for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:26:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4Sgl-0005Da-Pz for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:26:52 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:58198 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i4Sgl-0005D5-Jm for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:26:51 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i4Sgj-000pIt-Pa for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 18:26:49 +0200 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" To: emacs-orgmode@gnu.org Gustav Wikström 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.