Skip to content
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

Expose the Obsidian search parser or functionality #22

Open
esm7 opened this issue Jun 17, 2021 · 6 comments
Open

Expose the Obsidian search parser or functionality #22

esm7 opened this issue Jun 17, 2021 · 6 comments

Comments

@esm7
Copy link

esm7 commented Jun 17, 2021

It can be very valuable if the API would allow plugins to use the Obsidian note search syntax.
For example, Vault could have a search(query: string) method that returns a Promise<TAbstractFile[]> for the results of the search represented by query, which might include Obsidian search operators like tag: and others.
As of today, plugins wishing to implement a file search box currently need to duplicate this functionality, which is unfortunate because the query options that Obsidian supports make a powerful tool, and we rather use the same syntax in plugins.

As a nice bonus, it would be great to have a FileSearchQuery text box component that would show the user tips as in Obsidian's Find in Files pane and Graph View.

@lishid
Copy link
Collaborator

lishid commented Jun 17, 2021

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.

@thorlucas
Copy link

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
Copy link
Author

esm7 commented Jun 24, 2021

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
Copy link

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
Copy link

@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

@HananoshikaYomaru
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants