Kristoffer Balintona <krisbalint...@gmail.com> writes: >> Why not just using nil value as you initially suggested? > > Currently, both `org-capture-expand-headline' and > `org-capture-expand-olp' error when the expanded headline or olp, > respectively, return nil. I wanted to preserve that assuming there was a > good reason behind this decision. Do you think interpreting a nil value > in this way is more appropriate?
There is no need to preserve the behavior of `org-capture-expand-headline'/`org-capture-expand-olp'. Their purpose is basically parsing allowed values of olp/headline target. You are proposing to extend the allowed values, so it is 100% fine to handle nil without error - I will be a valid value now. The error should only be thrown when the user supplies invalid target. >> We used to have file+datetree target, and a number of others. They have >> been consolidated into a single file+olp+datetree in Org 9.1, 8 years ago. >> See >> https://list.orgmode.org/orgmode/CADn3Z2+AanLPvUO9ENhZ_2tkAvsmdnq9ewR3sFasn=zv--s...@mail.gmail.com/ > > Should we do the same with file and file+olp? Or would that be too > backwards incompatible? Backwards compatibility per se is not a problem. For example, file+datetree target is still working. It is just deprecated. However, forcing users to change their setup (even just because they start seeing deprecation warning) without an obvious counter-benefit is not a good idea. I do not see any significant gain from consolidating file+olp and file targets. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
