[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 ↩

[scambier]

Wow that's a lot 😅

I'm impressed (and glad) that this plugin is gathering such interest. I just wanted to solve my problem, and I absolutely did not expect that much feedback. So first, thanks for your enthusiasm and this post.

To make things clear, I built Omnisearch as an interface around MiniSearch, with the goal of having smart and fast search results. For me the search interface must be out of the way asap. I don't want to build complex queries, I just want to find what I'm looking for with 1-3 important terms. I think that this goal is achieved, and my problem is solved.

I'm happy to know that this plugin seems to also be useful to a lot of people 👐

The thing is, from now, I have to prioritize feature requests, and somehow balance what I'd like to work on (it's a hobby project after all), and what looks to be the most useful for other people.

If the community wants to get involved, I'll happily review and merge PRs

As long as there is a prior discussion on the feature to add, and that everyone is aligned on the implementation and user flow, I'm down with it. I'll write a CONTRIBUTING.md later to make those things clear.

All your suggestions sound good. However I try to follow the Unix philosphy of "do one thing, and do it well". Now obviously the "one thing" could be anything between "find a file" and "find anything". For now, I'd like to focus on the file search; there's still work to do (cf. the waiting FRs), and once this is done well enough, we can try to make Omnisearch really omniscient in the longer term.

[geoffreysflaminglasersword]

Wow that's a lot 😅

I'm impressed (and glad) that this plugin is gathering such interest. I just wanted to solve my problem, and I absolutely did not expect that much feedback. So first, thanks for your enthusiasm and this post.

To make things clear, I built Omnisearch as an interface around MiniSearch, with the goal of having smart and fast search results. For me the search interface must be out of the way asap. I don't want to build complex queries, I just want to find what I'm looking for with 1-3 important terms. I think that this goal is achieved, and my problem is solved.

I'm happy to know that this plugin seems to also be useful to a lot of people 👐

The thing is, from now, I have to prioritize feature requests, and somehow balance what I'd like to work on (it's a hobby project after all), and what looks to be the most useful for other people.

If the community wants to get involved, I'll happily review and merge PRs

As long as there is a prior discussion on the feature to add, and that everyone is aligned on the implementation and user flow, I'm down with it. I'll write a CONTRIBUTING.md later to make those things clear.

All your suggestions sound good. However I try to follow the Unix philosphy of "do one thing, and do it well". Now obviously the "one thing" could be anything between "find a file" and "find anything". For now, I'd like to focus on the file search; there's still work to do (cf. the waiting FRs), and once this is done well enough, we can try to make Omnisearch really omniscient in the longer term.

Yeah, I should have put in a TLDR, that's the response I expected. I'm mostly just getting the ideas out there for criticism, I plan to help out with this plugin in the coming months where I can. I figured other issues would be generated from this one after discussion, I don't expect all this to be implemented soon or in one go.

The main important changes, which I think are still in line with minimizing search interface are these:

• adding the (common) > symbol for searching commands (complicates interface slightly)
• excluding and hiding (doesn't complicate the search process, does complicate interface, but makes future searches less complicated)
• local and global switch and allowing tabbing between the 2 (somewhat simplifies the interface, since you don't need 2 separate hotkeys for vault and local search)

And to a lesser degree

• allowing symbol search (intuitive, doesn't complicate the interface)
• file type filtering (also doesn't really complicate interface)

Everything else is nice-to-haves, but those I think are somewhat critical and make Omnisearch into more of an application-wide search. The end goal for me personally is to be able to tap a single hotkey and go pretty much anywhere in the program without having to click or navigate anywhere

[geoffreysflaminglasersword]

Also I should have started this as a discussion, my b

[scambier]

local and global switch and allowing tabbing between the 2 (somewhat simplifies the interface, since you don't need 2 separate hotkeys for vault and local search)

This is the best change to include in short term, and it will maybe be useful for #4. I'm not sure if I'll use 3 contexts (global, local, workspace) or 2 (global, workspace), but anyway a tab press will be easier to navigate between them.

Also I should have started this as a discussion, my b

That would have been difficult, Discussions were disabled before that :)

[scambier]

So, this has again been asked here #203 (and at #98 before that)

I'm still against it because I think Omnisearch should focus on files, and other palette plugins do it well enough. If I add the commands in their own tab, it brings nothing over existing plugins. If I mix them with files, they might become too slow to find, as you might have to type more characters or scroll down. It will also require a code refactoring, as Omnisearch only handle files right now.

[xieve]

The part of this proposition that interests me the most is using Obsidian as the backend for the existing vault search dialog. In my opinion, this fits into the original scope of the plugin and is in the "Do one thing, and do it well" spirit.

I am using these plugins:

• Better Search Views
• Quick Switcher++
• Float Search

Together they provide a very beautiful, modular and quick-to-parse experience in my opinion. But they all rely on Obsidian's native un-indexed search function, which is just too slow.