Ihor Radchenko <[email protected]> writes: > Khalid Rafi <[email protected]> writes: > >> But, one can have a case as simple as: >> #+begin_example >> * TODO read 20 pages of the book [10/20] >> #+end_example > > This feels not reliable because one may later add a checkbox or > subheadings. Then, whatever information is stored in the cookie will be > lost by auto-updates.
As I said, if a certain entry with cookie has no subheading and contains those properties, we'll use them to calculate. If he adds subheadings, the values should be there in :PROPERTIES:. But, we'd ask users to also add this very heading into subheadings and make a new top heading when he changes mind. >> If this is impossible, we would need: >> #+begin_example >> * TODO read book [10/20] >> ** DONE read 20 pages >> :PROPERTIES: >> :COOKIE_COUNT: 10 >> :COOKIE_COUNT_MAX: 20 >> :END: >> #+end_example >> >> We are modifying the cookie via the properties COOKIE_COUNT and >> COOKIE_COUNT_MAX. If a certain entry with cookie has no subheading and >> contains those properties, we can additionally use that to calculate the >> cookie. Then, if changing the cookie [/] values by hand and doing C-c C-c >> (or org-shiftup) could modify those properties, this might work. The idea is >> similar to LOGBOOK. > > An alternative idea could be merging the two properties into one > :COOKIE_COUNT: [10/20] Instead of showing in the heading? And, can't we follow how LOGBOOK dates can be modified and it adds the time diff at the end? And, also how we can use shiftup to increment the date along with the diff? -- Khalid Rafi Sent with Emacs
