Oni: Thoughts on the new global search

[nwaywood]

Hi all, I just updated to 0.3.0 which has the new "VS Code" style sidebar with global search and I wanted to give my input about an alternative implementation (I sincerely hope that no one takes any offence to this).

I personally prefer the approach to global search that emacs-helm, atom-narrow and unite.vim take. The advantages of this style of approach include:

• You get a consistent UI for narrowing lists of different types of data sources instead of a specific UI for just global line-wise search (i.e. ripgrep). For example, with the tools listed above you can use to same UI for local symbol search, global symbol search, global line-wise search, local line-wise search, local folds and more
• It can be made to be extensible (just like how you can add your own custom sources with unite.vim)
• Quicker to visually parse because the input text field is co-located with the results
• This last point is quite opinionated, but I also feel that this approach is more "vim-like"

Looking forward to hearing your thoughts on this :)

[bryphe]

Thanks for the feedback @nwaywood ! Really appreciate the thoughtful suggestions.

(I sincerely hope that no one takes any offence to this).

Haha, not at all, it's totally constructive!

You get a consistent UI for narrowing lists of different types of data sources instead of a specific UI for just global line-wise search (i.e. ripgrep). For example, with the tools listed above you can use to same UI for local symbol search, global symbol search, global line-wise search, local line-wise search, local folds and more

I do like the proposal - an experience like atom-narrow seems like it would fit right in to Oni.

It can be made to be extensible (just like how you can add your own custom sources with unite.vim)

Yes, this would be cool. Similiar to what we're doing for some other parts of the API (like completionProviders in #1329)

Quicker to visually parse because the input text field is co-located with the results

👍 - our UX is a bit awkward at the moment.

This last point is quite opinionated, but I also feel that this approach is more "vim-like"

That's fair! This is a bit embarrassing to admit, but the main reason it is in the sidebar today is because I wanted something else to showcase there aside from the file explorer (so not a very compelling reason). It wasn't really placed there in consideration of the best / most productive UX, which some of these points could help move us towards.

I like having the consistent experience between symbol search, global search, etc. Some other thoughts in #776 too.

[nwaywood]

I do like the proposal - an experience like atom-narrow seems like it would fit right in to Oni.

I'm so glad you agree, imo atom-narrow in Oni would be amazing! I use it daily in Atom.

That's fair! This is a bit embarrassing to admit, but the main reason it is in the sidebar today is because I wanted something else to showcase there aside from the file explorer (so not a very compelling reason). It wasn't really placed there in consideration of the best / most productive UX, which some of these points could help move us towards.

Yeah I have mixed feelings about the existence of the sidebar in VS Code. I understand its good because it helps with discoverability and access (for people who use mouse) of key editor features. But its bad because it takes away horizontal space from the editor windows and also feels a bit like "all these features are important and we want users to be able to find them easily, so lets just throw them together in a bar". I ended up disabling it in VS Code because of the horizontal space I was losing and because I use keyboard shortcuts instead of mouse for things like that anyway.

[pcvonz]

I second all of this. I Haven't used atom-narrow, but I have used unite (dnite) and still do in Oni. An oni implementation of Unite would be excellent!