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 16:08:03 +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]:53249) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4SOg-0008OM-9z for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:08:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4SOe-0007YG-Jw for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:08:09 -0400 Received: from mail-eopbgr150134.outbound.protection.outlook.com ([40.107.15.134]:54360 helo=EUR01-DB5-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 1i4SOe-0007X9-7Y for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 12:08:08 -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" Hi Adam, > 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? >=20 > 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:=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! I've made specification-changes only at two locations in the test-cases for org-element. (ref. patch nr.1)=20 Best Gustav