John Wiegley <jwieg...@gmail.com> writes: >>>>>> Aaron Ecay <aarone...@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
