Cancelled. As I am now employed, I no longer can assign my copyright.
Le jeu. 30 juil. 2026 à 20:44, Earl Chase <[email protected]> a écrit : > > Le sam. 25 juil. 2026 à 11:28, Ihor Radchenko <[email protected]> a écrit : > > > > Earl Chase <[email protected]> writes: > > > > >> We also need other similar commands. For example, org-agenda-todo-at. > > >> > > > > > > I added `org-agenda-todo-at' as a separate patch. Both > > > `org-agenda-todo-at' and `org-todo-at' only use the interactive > > > version of `org-read-date' when they are called interactively. > > > > The way it is implemented feels like too much copy-pasting. > > Maybe we can extend org-todo itself to accept optional argument TIME > > that can be nil (current time), 'query - query interactively, or a > > string - time to be used. Then, the code will be less repetitive I think. > > > > Also, I noticed that time is forced to be present even when I do not > > enter it, and defaults to current time. It does not feel right. Maybe we > > need to put 00:00 or something. > > > > > But > > > the specific problem that I was referring to is more complicated than > > > that. In addition to the `org-todo-at' patch and the > > > `org-agenda-todo-at', I created another patch with a simple test that > > > shows why this approach makes it impossible to test `org-todo-at' with > > > repeaters, for the moment at least. You will see that when you call > > > `org-todo-at', LAST_REPEAT gets set to the correct value but the > > > repeater itself is not set to the right value. I still haven't found > > > the root cause of this issue. But I do know that LAST_REPEAT is always > > > set to the correct time because `org-auto-repeat-maybe' directly uses > > > `org-current-effective-time' to create the new value of LAST_REPEAT. > > > On the other hand, `org-today' and `org-timestamp-to-now' are the > > > functions that `org-auto-repeat-maybe' uses to actually update a > > > repeater. Those functions of course can be overridden. But I think a > > > better idea would be to create org versions of `time-to-days', > > > `time-since' and `float-time', as those are the functions that > > > `org-timestamp-to-now' and `org-today' uses internally. I still don't > > > understand why none of that is needed for manual tests. > > > > Yes, that would make sense. > > (And yes, this is why this patch is less trivial that one may think; > > especially if we want to support effective time across Org) > > > > In order for org to properly support effective time, we need the following: > > - org-time-since > - org-float-time > - org-time-to-days > - org-decode-time > - org-current-time-string > - org-format-time-string > - org-time-less-p > - org-time-equal-p > - org-time-add > - org-time-subtract > > The issue is that besides `org-time-to-days', > `org-current-time-string', `org-time-equal-p', all of the functions in > the above list are currently obsolete function aliases. So I'm not > sure what the process for un-obsoleting functions is, but that is one > of the things that will have to be done here. > > Obviously once those functions are written, they will need to be used. > So we will have to go through the org code and replace all time-* > functions with org-time-* functions. It would also need to be made > clear to contributors that they need to use org-time-* functions for > any new code. > > Then, I think the next step should be to combine `org-current-time' > and `org-current-effective-time'. The current state where we have both > functions is very confusing. Just based on the way custom variables in > org-mode usually work, you would expect `org-use-effective-time' and > `org-extend-today-until' to directly override `org-current-time'. > Instead those variables, indirectly override `org-current-time' via > `org-effective-time' More importantly, if the goal is to support > effective time throughout Org, we are going to end up replacing almost > every single use of `org-current-time` with > `org-current-effective-time' anyways. But that's a minor issue, a > quick search of the org code shows that the reason most of the > org-mode ignores effective-time for the moment is due to the use of > functions like `time-add', `time-to-days', `time-since', etc.
