What is the reasoning behind the design of not inheriting the SCHEDULED and priority properties?

Any notable use cases to support this behavior?

On the contrary, actually inheriting SCHEDULED (or DEADLINE for that matter) and priority properties makes perfect sense to me.

For instance, if an entry is SCHEDULED and thus is appearing in the week agenda, adding a sub-item to it will automatically bring that item to agenda replacing the parent. This will prevent the parent from falling out of attention. In the current design you may loose a DEADLINE task forever by adding a sub-task to it without scheduling it.

  • 1
    I agree this feature is weirdly lacking. Are you trying to add this feature and getting stuck somewhere in the code? – purple_arrows Apr 13 '18 at 21:22
  • 1
    The function that handles this stuff is org-entry-get. For values in org-special-properties (including SCHEDULED and DEADLINE) it uses org-entry-properties, which doesn’t support inheritance. For other values it uses org-entry-get-with-inheritance. So one way to add support would be to rewrite the first function. Another way would be to rewrite the second function to handle org-special-properties and take out the first case. – purple_arrows Apr 13 '18 at 21:26
  • @purple_arrows has there been any development on this front since 2018? – Matthew Piziak Jun 12 '19 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.