search

alphapapa / org-ql

A searching tool for Org-mode, including custom query languages, commands, saved searches and agenda-like views, etc.
GNU General Public License v3.0
1.41k stars 110 forks source link

Sibling predicates #105

Open Zetagon opened 4 years ago

Zetagon commented 4 years ago

I currently depend on https://orgmode.org/manual/TODO-dependencies.html to hide tasks that are not relevant now. It is possible to do a query for filtering out tasks blocked by subtasks but I don't think it is possible to implement ordered tasks because there is no sibling predicate.

Will sibling predicates be implemented?

akirak commented 4 years ago

You can use org-entry-blocked-p to check if an entry is blocked, and its result is available as BLOCKED property. In org-ql, you could use (property "BLOCKED" "") for selecting non-blocked entries. However, dimming would require a further implementation.

Zetagon commented 4 years ago

I personally don't need dimming so it's alright.

alphapapa commented 4 years ago

@Zetagon You titled the issue about hiding or dimming, but your question seems to be about sibling predicates.

A sibling predicate is an interesting idea. It could probably be implemented pretty simply. Can you give me some example use cases? That is, pretend that there's a (sibling) predicate that works the same as, e.g. (parent). What would you use it for?

Zetagon commented 4 years ago

The goal was to hide blocked tasks in the same way as described in the link, which is why I titled it the way I did. That way you can have ordered tasks where only the first task in that subtree is shown. It is very handy when describing tasks that are only relevant after the previous ones have been completed.

This query would only show subtask 1. After subtask 1 has been completed subtask 2 would be shown.

(and (todo)
     (not (sibling-above (todo))))
* Project
:PROPERTIES:
:ORDERED:  t
:END:
** Non-task heading
** TODO Subtask 1
** Another non-task heading
** TODO Subtask 2
** TODO Subtask 3

I asked about sibling predicates because that would solve the problem in a very general way.

As for the api, I think there has to be some sense of direction, i.e. siblings above or siblings below current task. I think that it would also be nice to have a predicate for an immediate sibling(i.e. one entry above/under) or a sibling arbitrarily far away(e.g. Subtask 1 and 3 are still siblings). In other words, there would be one predicate that works in the same way as parent, ancestor, child and descendants but for siblings instead.

Btw, org-ql is an amazing package. It is so nice to write queries in it!

alphapapa commented 4 years ago

Thanks for the example and thoughts. I agree, that could be very useful. I probably won't work on this soon, but I'll plan to add it in the future, maybe in version 0.6.

alphapapa commented 3 years ago

Since it's been so long since the last 0.x release, I'm going to defer this to 0.7 in an effort to reduce the scope of 0.6 and release it sooner.