-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timestamp ranges not matched the same way org-agenda does #237
base: master
Are you sure you want to change the base?
Conversation
I may be mistaken, but I don't think it's valid to use a range timestamp as an entry's SCHEDULED timestamp. |
I may be mistaken, but I don't think it's valid to use a range timestamp as an entry's SCHEDULED timestamp.
It is indeed discouraged in the manual. However, org-agenda does show
scheduled entries with scheduled timestamp being a time interval.
Also, `ts` predicate will not match timestamps with interval (see
`org-ql-regexp-part-ts-time').
|
Well, I guess we'll have to do it too, then. :)
Hm, I thought I had that covered, but maybe I overlooked it. Thanks. |
Retargeting this for 0.7. 0.6 has been delayed for too long. |
It's also relevant for |
4f5fbc4
to
d0acc8c
Compare
Anything hindering this pr to be merged? |
scheduled time-range now covered this is the code from alphapapa#237
@enko Well, yes: since this has been a bug, the fix should be accompanied by explicit tests, i.e. there should be a new test added for timestamp ranges, rather than just changing one of the test data entries, as the PR currently does. Maybe even multiple tests for active/inactive timestamps, in planning/deadline/scheduled lines, and in headings/content. It also needs a changelog entry--which I typically take care of myself when merging, but if a contributor provides it in the patch, it saves me the time and makes it easier for me to merge (assuming it's done correctly; even when I ask someone to provide one, and they do, it usually contains typographical errors that I have to fix myself, which defeats the purpose). Other than that, the limitation is time, which I don't have as much of as I used to. In the meantime, you're free to use the PR's code and report back as to how well it works. Any bugs you could discover before merging would be helpful. |
As well, fixing this properly probably requires more work, because a ranged timestamp essentially represents two timestamps, one at each end of the range, and searching for timestamps within specific ranges must account for both of them. |
Do you think it's possible to split this is up into two tasks:
I came here look for 1, looks like I'm not the only one. Would be happy to contribute tests for it as well and improve the original request. |
I tried out your most recent commit @dmitrym0 and had no luck with either the scheduled predicate or the ts-active predicate. |
Here's a part of my test data:
and the associated org-ql query that returns it:
|
Ack, sorry. A (Doom) Emacs restart ensured I was actually using the package built from your commit, and now everything works. Cheers! It all works a charm. |
059b10c
to
77b4c2b
Compare
I'm getting more friction from this issue lately as I now use a visual timeblock library that I find very helpful for me that depends on time ranges to work: https://github.com/ichernyshovvv/org-timeblock So... I'm interested in contributing here but I'm unclear on exactly the target is for it being done and being reasonably sure there are no regressions. I see:
So from that the checklist in my mind would be:
I think if we could figure out a checklist that is likely to get merged or not get stuck because of a lack of confidence we can make progress on this. My biggest question and perhaps also the biggest unanswered question for you is where the other code is that needs to handle timestamps for a change like this. Perhaps just adding the tests above or perhaps the above and any additions you may add will answer the question of what those places are? |
Echoing @ParetoOptimalDev , what are the exact things that would need to be done for this to be complete? It's 100% understandable if you cannot make this a priority, @alphapapa . This project is big and we are lucky that it works already as well as it does 😃 If you are able to enumerate the actions required, maybe others can complete them. |
@ivanperez-keera I'll try to summarize what comes to mind:
Looking back, I suppose this was a somewhat significant oversight on my part, to not realize that timestamps can have time ranges (something I never use in my own Org files). Thankfully it seems that not many other users use them, or else Org QL would probably be much less useful than it is. Anyway, that's what comes to mind. Actually digging in to the code might reveal more or fewer problems to deal with. If someone who has done the FSF CA wants to work on this, I'll be glad to provide feedback (but with the caveat that I aim for very high quality code on this project, and I'm very particular (realizing of course that there are probably people out there who think my code is atrocious, haha)). |
org-ql together with timestamp ranges enables some pretty advanced forms of planning. I manage everything I do with org-mode, both at work and in my personal life, and scheduling tasks with ranges allowed me to plan full weeks of tasks with minute precision -- and stick to the plan. I hope someone who knows lisp can help by sending a PR that meets Adam's requirements. I can contribute by trying this on large files. Not sure if that will help, but I'll happily buy whoever works on this a few rounds of coffee, or a drink of your choice -- whatever keeps you going while you code :) |
I'd like to read more about that, because it would be helpful to me too.
FWIW, I do intend to see that this is solved, whether the code is written by me or someone else. It's just a case of limited time and professional priorities right now, for myself to do it. If someone were interested, I'd be open to the idea of the work on this project feature being sponsored, either by an individual or through a bounty program; that would allow me to prioritize doing the work myself. |
I've been meaning to write about this, but --not a joke or some messed up passive aggression-- lately finding time has become hard because of this missing feature 😅
That's absolutely understandable. I'm on the same boat with the projects I maintain.
I'd be open to this. I say let's try it. I don't know how big a bounty we are talking; I doubt I'd be able to contribute a big enough amount to change your priorities, but if several of us are willing to chip in, then maybe we'll get there. Also, it may make sense to let others who submit a PR take the bounty even if we don't get to an amount that would allow you to do it. They may have a bit more time and be willing to do it even if you can't. |
LOL :) Regarding a bounty: I'd probably only be willing to be involved in something like that if it were explicitly intended, from the beginning, to sponsor my working on the feature, not anyone else. The reason is not to deny anyone else the opportunity to work on it and benefit from a bounty. The reason is that, if someone else did the work and wanted to claim the bounty, I would still be involved, as it would be my responsibility to evaluate the code and decide whether to merge it; and if I rejected it, or if I required changes that the other developer did not want to make, I would not want to deal with conflict over whether the bounty should be claimed, whether it should be divided among various participants, whether my requirements were reasonable, etc. Whereas, if I were doing the work myself, I would naturally do it in a way that I would approve of and merge. So I think it would be better considered as an opportunity to sponsor the author to implement a specific feature with priority over other features. Of course, I can't control what anyone else does; if someone were to start a bounty somewhere, and that resulted in code being submitted (with proper copyright assignment), I wouldn't necessarily reject it. But I would not give any consideration to the bounty being involved. My objective is only to have high-quality code implementing useful features in a well-integrated, maintainable way. This is why it's important to coordinate such things with project maintainers in advance. I hope you understand what I mean. When money gets involved, everything changes, and one has to be very careful. It's best to be as clear as possible from the beginning. |
I rely on scheduled time ranges heavily, though org manual seems to discourage this. I wrote a small package to plan my days: org-hyperscheduler. I use org-ql to surface tasks and task-like things though |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This sub-thread seems to be about the semantics of SCHEDULED timestamps as interpreted by users and as implemented by Org Agenda. But this issue is supposed to be about Org QL's support for timestamps with internal time ranges. So, yes, please continue it on the mailing list, or on a thread on this repo's Discussions forum. If you do, feel free to post a comment here with a link. In the meantime, I'm going to mark the relevant comments here as off-topic so the issue can remain focused on the technical issues regarding Org QL. No hard feelings; conversations work this way. :) |
I have a headline like the following:
I expect this headline to be matched by
(scheduled 0)
sexp, but it is not.