Re: Allowing loose ordering in Org files

[Matt Lundin <mdl@imapmail.org>]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Aaron Ecay <aaronecay@gmail.com> 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