consult-org-heading filtering

[lyndhurst]

I am trying to filter candidates presented by consult-org functions with little success so far.
Files considered can be easily defined using the SCOPE argument, but the MATCH seems pretty limited for what I could test so far. I wish I could use a lambda predicate or something like that.

For example, if I want to only be presented with TODO entries, I can use "TODO=\"TODO\"", but I cannot use regex to match any TODO keyword like "TODO=\".*\"", or even "TODO=\"TODO|NEXT\"".

Is there a way to filter the list of candidate with more control than what I managed to do so far ?

Thanks for your time.

[minad]

You can press narrowing, press SPC t in the beginning to see only TODO items. Besides normal text filtering, there is no additional option to filter on heading properties. You may want to consider org-ql.

[lyndhurst]

I was aware of consult-org great 'narrowing' capalities within the function. I am looking for a programmatic 'pre-filtering'. I am still trying to be able to hack at consult-org functions, because they are just great to navigate org entries. I have difficulties understanding the code, but I found this function on the great Sacha Chua blog, and it is a great start for now. Thanks for taking the time to answer.

[minad]

Okay, I see. Consult doesn't offer anything beyond what is offered by org-map-entries for programmatic pre-filtering. I had assumed that this is sufficiently flexibility and offers predicates, but I am not deeply familiar with the Org API and its internals.

[lyndhurst]

I am personally grateful those functions exist at all :)

For what I have learnt so far org-map-entries offers the same filtering as the advanced search syntax used by the agenda. It is great, but has some limitations, especially for over-engineered org setups which are pretty common among new comers (as I kind of am). imho, it gives the user total control over the SCOPE part by allowing to directly pass a list of files; but the MATCH argument is not as critical since a user can add all the filtering needed inside the function.

Those limitations are the reason why I rely heavily on org-ql and org-ql-blocks instead of regular org agendas. The link I shared in my previous code will hopefully allow me to understand better how the code works. I did not get around to study it yet, I only tested it.

Anyway thanks again for taking the time to answer here, and share this very helpful package as well.

[minad]

specially for over-engineered org setups which are pretty common among new comers (as I kind of am)

Then don't do that? I mean in particular if you are already aware that you are over-engineering? I think my Emacs setup and packages are only good because I try to make them as simple as possible. Occasionally this means to pass on features if they don't fit the bigger picture.

I very often see extremely large Emacs setups with tons of custom functions. I think this is not ideal since code cannot be shared (or only shared via copy and paste). If you start writing a large number of custom functions, try to organize them into related groups and turn them into small local packages, which could even be distributed to others. See Omar's setup as an example: https://github.com/oantolin/emacs-config/tree/master/my-lisp. I think also Prot uses that approach with his *-extras.el packages and sometimes he extracts new packages for others.

[lyndhurst]

Thanks for the links, I definitely need example of well structured configs.

It was some kind of self-derision on my part, even if yes, my current set up is over engineered. I think this is part of the learning process for some of us; I have only been using Emacs for around 6 months (loving it btw) and there are so many possibilities, so many things to learn, it is hard to stay focus.

I completely agree with you, simplicity is what makes any system great but the learning process is usually a messy journey to get there. The most important thing is to be aware of the mistakes made along the way and of the role they play in that journey instead of getting frustrated or discouraged by them.

For Emacs, structuring my config into small packages is my next planned big step so those examples will come in handy. And I am sure the process itself will rid me of many redundant functions I added along the way. This question I am asking is actually part of a simplification process as I am currently redesigning the task part of my setup.