[Feature request] Unify with Quick Switchers and Command Palette

[geoffreysflaminglasersword]

Just to preface, I don't want to sound demanding or inflexible, I plan to help out with the development after there's been discussion on how much of these features are appropriate.

What Omnisearch should be

Imo, the search improvements of this plugin are wonderful yet half the battle. Making Omnisearch truly "Omni" for all of Obsidian would require unifying the Command Palette and Quick Switcher and the best parts of their various plugin counterparts.

There are quite a few search oriented plugins out there, here are features I've found useful in some of them:

General CP+QS+Obsidian:

• pinned results
• show only existing files
• show all file types
• excluded files are downranked in the quick switcher
• switching vaults

Quick Switcher++:

• searching workspaces with + (but doesn't allow styling or creation+renaming like Workspaces Plus's "Open Workspaces Plus" command¹)
• searching symbols (heading, tags, links, embeds) with @ or just headings with #
• searching open views with edt (mainly useful for Sliding Panes users who have many panes open at once)

Better Command Pallet:

• search commands
• search files with /
• search tags with #
• hide commands (especially useful for commands you know the hotkey for or will never use)
• ctrl+I toggles hidden items
• shows recent commands at the top ²

Proposal

I welcome feedback on this of course, but here are my thoughts...

High Level

We have several different categories of things that can be searched: text, symbols (tags, headings, links, embeds), files (markdown and non-markdown) , commands, views, workspaces, and vaults. I could add to that list snippets and plugin settings, since those are searchable through the settings menu.

Also, we have 2 styles of exclusions. Hiding (from Better Command Pallet) makes the query result invisible, and its visibility can be toggled. Excluding files and directories (built in to obsidian) simply downranks results.

In Detail

Rather than adding and having to remember 10 different query starting symbols (like the ones mentioned above and in #2), my thought is this:

• have 2 different modes, local and global
• in either mode, one can access the system mode by typing ; (or > from text editors like VS Code)
• one would switch between local and global using the tab key (since it is both easy access and next to useless while searching) or by clicking a toggle at the top of the modal. This toggle will visually indicate which mode you're in whether tabbing or clicking.
• A user would be able to hide commands in the system mode and files in global mode
• Exclusions set in the settings just downrank matched file's results and don't affect anything else

The categories can be queried as follows:

• File+Text: the default search in both local and global
  • (already implemented) this searches both file names (in global only) and content, unifying search and Quick Switcher
• Symbols: searchable using symbols you'd expect ³
  • want to search headings? type # heading or ### heading ⁴
  • tags? #tag (no space)
  • embeds? !
  • links? [
• Commands: the default search in the system mode
• Plugin settings: ctrl+enter on any command to go to the settings page for its plugin
• Snippets: ignore for now, likely not super useful
• Views: also in the system mode (only if enabled in settings)
• Workspaces and Vaults: potentially by typing a second ; (e.g. ;;Vault)
• specific file types - by typing the extension first, e.g. png.image or pdf.book title
  • could also accept png:image

Recency

Recency functions differently for different items. All text search should incorporate file recency into its ranking, both search recency (higher priority) and modification recency (lower priority). Recency would of course have lower importance than text matching.

All other recency would function as you'd expect (most recent command, view, plugin, etc.), but it should be configurable how many to limit to in the settings - maybe I only want the 3, 5, or 10 most recent (or 0 for all).

Footnotes

Footnotes

1. ↩

2. ↩

3. Symbols will simply be up-ranked above text results, not filtered-for. Since there are (uncommon) cases you may be searching for text starting with those symbols, their could be a setting/command to toggle symbol up-ranking. But I can't imagine anyone legitamately searching for something starting with any of those symbols, like #1. Exclamation marks could be in search but likely with text preceding them, and brackets are also uncommon (the user would be more likely to search the text within brackets anyhow). ↩

4. headings could be searched and ranked according to the number of #s in the query. I.e. heading results would be ranked with level 1 at the highest and 6 at the lowest, but a query like ### abc would downrank levels 2 and 1 ↩