From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Gustav_Wikstr=F6m?= Subject: Re: [RFC] Org document concept + document property drawers Date: Sun, 1 Sep 2019 19:12:48 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47982) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4VHS-0001RW-2p for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:12:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4VHQ-0001NO-Mz for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:12:53 -0400 Received: from mail-eopbgr50111.outbound.protection.outlook.com ([40.107.5.111]:52898 helo=EUR03-VE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i4VHQ-0001Ke-AL for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:12:52 -0400 Content-Language: en-US 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: "adam@alphapapa.net" Cc: "emacs-orgmode@gnu.org" > From: Adam Porter > Gustav Wikstr=F6m writes: >=20 > > Previous tree:=20 > > (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=20 > > in my opinion. Everything else works as before AFAIK... But I might be= =20 > > overseeing something. Please enlighten me in that case! >=20 > Thanks, that's a helpful illustration of the difference. >=20 > I'm glad that it only changes the result of parsing entire buffers. > That will limit the breakage. >=20 > 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. >=20 > 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. =20 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