Expose the Obsidian search parser or functionality about obsidian-api

[lishid]

I agree we should eventually expose some of the search & result rendering APIs.

Right now it is fairly difficult because they are fairly specialized for the use cases we need, so the API is quite specific and confusing for the general use case. The other design challenge is the entire performance optimizations mixed in with the API; Obsidian's search uses many javascript and DOM tricks to avoid freezing the app when searching through thousands of files, which makes exposing this even more complicated.

I will look into this eventually though, just hang tight.

[HananoshikaYomaru]

@esm7 @lishid in obsidian 3d graph, a custom search input is built to get builtin obsidian search result. By combining reset function, I made search(query: string) to Promise<TAbstractFile[]> works.

[thorlucas]

Perhaps at least if search functionality isn't exposed, then certain filters on TFile[] should be. Having to maually write filters to check if a TFile contains a tag, or if it belongs in a path, seems redundant.

[esm7]

I'm personally ok with even a softer version of that: it'll be helpful even if just the parsing is exposed, e.g. I'll supply functions to check if a TFile contains a tag etc., and the API method will parse the string (including all the supported operators) and return if it matches or not.

[classicrob]

If I could write searches and save results from my code, then that would enable a plugin for incrementally processing notes! Right now I need to search in Obsidian, copy the results to my clipboard, paste into Excel, and then run the code. Ideally, I would be able to collapse the last three steps into the second step. https://twitter.com/roberthaisfield/status/1413561714205888514?s=21

[paulbricman]

@classicrob that sounds a bit like the incremental writing plugin (https://github.com/bjsi/incremental-writing). It uses the obsidian search to add notes to a queue, but not sure how it does that