From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Re: Allowing loose ordering in Org files Date: Tue, 10 Nov 2015 11:51:28 -0600 Message-ID: <87h9ktoi8v.fsf@fastmail.fm> References: <871tc83p01.fsf@flynn.nichework.com> <84611j19hk.fsf@gmail.com> <5638C2A1.2090801@iancu.ch> <87h9l32gfc.fsf@nicolasgoaziou.fr> <87d1vq3mh4.fsf@nicolasgoaziou.fr> <874mh23iw0.fsf@nicolasgoaziou.fr> <878u6eu5wg.fsf@Rainer.invalid> <315DDEDC-1BD9-4680-A8C8-B36821EB931C@gmail.com> <874mh2u2w0.fsf@Rainer.invalid> <87ziytyl3z.fsf@free.fr> <877flqskci.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwD4x-0004fU-8J for emacs-orgmode@gnu.org; Tue, 10 Nov 2015 12:51:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwD4u-0003ZP-2p for emacs-orgmode@gnu.org; Tue, 10 Nov 2015 12:51:35 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwD4t-0003Xu-T5 for emacs-orgmode@gnu.org; Tue, 10 Nov 2015 12:51:32 -0500 Received: from archthink (c-50-172-132-15.hsd1.il.comcast.net [50.172.132.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C87756800CE for ; Tue, 10 Nov 2015 12:51:28 -0500 (EST) In-Reply-To: (John Wiegley's message of "Mon, 09 Nov 2015 17:52:35 -0800") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org John Wiegley writes: >>>>>> Aaron Ecay writes: > >> Adding knobs to this parser increases the burden of those who have to build >> and maintain it. > > Thank you for your reply, Aaron, I found it most illuminating. > > If the answer from the maintainers is "It's more work than we want to > do", that's completely acceptable. I've been operating under the > premise that it wouldn't be difficult to add such an option (just the > hook, mind you, not the functionality behind it). After looking quickly at the code, my impression is that without substantial refactoring, a hook/variable pointing to an alternate "find property drawer" function is not a very clean option, since org makes the assumption in several places that the property drawer comes immediately after the planning info. See, for instance, org-insert-drawer, org-end-of-meta-data, org-get-property-block. If you were to hack something on your own, I suppose your could rewrite/advise org-get-property-block, but I have no idea what else that would break. > If my request is fulfilled, I would expect that changing the "find > properties function" would imply that one's Org file is no longer > usable by secondary interpreters. I.e., "If you change this, you do so > at your own risk". [ ... quoted from another email ] I would vote against creating a hook or variable that comes with a warning "change this at your own risk." I am concerned about the precedent this would set. This seems to me what defadvice is for. Would this really be a simpler option than posting a hack on emacswiki or github? After all, anyone customizing the variable would still have to grab the custom function from github, etc. IMO, to add a customization option that might (and probably will) break other parts of org mode threatens to add complexity to the maintenance of org, since it might create a base of users who are relying on a "semi-officially supported hack" rather than the official parsing logic supported by org. Despite the disclaimer, maintainers will still be forced to keep the possibility of this customization in mind when rewriting functions that parse org syntax. And even if a user accepts the full risk of the customization, it is still possible that he/she might accidentally report a bug to the mailing list when something breaks (not realizing it is related to the customization). In short, if we allow for an alternative parsing logic, I think it should be one that is officially supported/maintained. Best, Matt