Show quick open results as preview while navigating through them

[drew-wallace]

• VSCode Version: 1.3.0
• OS Version: Windows 10 64bit & Mac OS X 10.11.3

Steps to Reproduce:

1. Open the Quick Open box
2. Type a file name that returns several results
3. A new Preview editor pops up and receives focus with the first result loaded into it
4. Scroll through the results in the Quick Open box and the Preview editor changes to the file that's highlighted
5. Selecting a result will fully open the file. Canceling can close the Preview editor or leave it open. I'd prefer if it closed the preview.

[bgashler1]

I myself have been wanting this very same thing. I tend to open several files up front, and then I have to double-click each one.

I think that opening something via Quick Open as a fully-opened file makes sense in this case, because if you had the opportunity to see a preview and still committed via enter or a click to open it then you probably intend to keep it around for a while.

[drew-wallace]

Just to be clear, the point of this is to see the contents of a file as I scroll through the results of Quick Open. As far as permanently opening a file from quick open, that would be good too.

[stevencl]

Previewing files as you move up and down the list of results makes a lot of sense. For files that are currently open we would bring them to the front.

[bgashler1]

UX meeting notes
We agreed that this is a compelling interaction need. We considered how competing products handle this, and we found that Visual Studio IDE handles it best. We will apply the relevant Quick Open interaction patterns:

• Quick Open will now create a preview editor (or leverage the already open one, if one exists) to show you a preview of each item you focus on in the list.
• Upon hitting Enter, the open editor will be kept open (i.e. no longer preview).
• If a user hits Esc or clicks away from the Quick Open command palette…
  • The command palette will close and whichever open editor you were on before previewing will be brought back in view.
  • The preview editor will remain and whatever you last were looking at in Quick Open will also remain inside that preview editor—exception: if you were already on a preview editor when you opened Quick Open and previewed some items but never selected any (e.g. escaped out of it) then we will restore whatever you previously had open in that preview tab, since that would indicate that the preview tab is likely something you want to keep and not replace. Otherwise, if you didn't already have a preview editor open before previewing in Quick Open pressing Esc will remove the preview editor as if nothing happened.

Bold = addition
Strikethrough = deletion

[smuuf]

I'm glad I found this issue (under this not-so-much clear title), so I don't have to create it myself.

I just got annoyed by this behaviour of closing files - I evidently wanted to have opened - for the 451th time in the last two weeks.

Please, let's make it into the next release. :)

[wprater]

Ive spent some time working through this. Have a good understanding of the organization of the editorPart, groups, stack model, etc. Pushing up a PR, but I'd really like to fix some UX issues below.

The preview editor will remain and whatever you last were looking at in Quick Open will also remain inside that preview editor—exception: if you were on a preview editor when you opened Quick Open and previewed some items but never selected any (e.g. escaped out of it) then we will restore whatever you previously had open in that preview tab, since that would indicate that the preview tab is likely something you want to keep and not replace.

I think a better UX would be to close a preview editor if there were none open. Hitting escape should remove all side effects e.g. opening a new preview editor.

Upon hitting Enter, the open editor will be kept open (i.e. no longer preview).

Would we prefer to honor the user preference workbench.editor.enablePreviewFromQuickOpen (this is how Ive implemented it)

[wprater]

Another UX issue that I discovered while previewing in a current previewEditor: the scroll positions are lost.

We could keep track of a selection/cursor when opening with TextEditorOptions, however, this feels kind of kludgy to keep track of this just if we are swapping the contents of a preview editor. An easier approach could be to render a tab-less editor that would be show while previewing files that are not find in the current editor groups.

Thoughts?

[drew-wallace]

Sublime preserves the cursor position of each file, and when you preview that file, it shows the cursor in that position. If you haven't visited that file before, it defaults to the top of the file.

[wprater]

Sublime preserves the cursor position of each file, and when you preview that file, it shows the cursor in that position. If you haven't visited that file before, it defaults to the top of the file.

actually, they use a brand new editor buffer when displaying a file that has no editor associated with it. otherwise, you're effectively just swapping the viewable editors (VS Code also will preserve line and viewport position in this respect). this is what Im doing now in my PR.

Im lobbying for a new buffer with no tab, so we can have a similar experience to what ST has.

[drew-wallace]

Also, Sublime will put focus on an open tab if what you have selected in Quick View is already open.

[wprater]

yeah, see my PR. these behaviors are implemented. :)

[bpasero]

@wprater yes, the preview editor has to go away when I cancel my quick open session without picking an item. I cannot see how the scroll positions can get lost unless you actually provide options with line/col information. We always persist the view state of the editor and restore it on open unless you provide your own view state.

[wprater]

We always persist the view state of the editor and restore it on open unless you provide your own view state.

The issue is that I need to render another temporary editor and display it as an eager preview. Its not really a preview (or pinned) editor until one selects it.

Do you know of a method in which I could create such an editor? I can keep looking around, but if there are some mechanics already, I'd like to utilize them.

[bpasero]

@wprater I do not understand why you would want to open a temporary editor...

[wprater]

@wprater I do not understand why you would want to open a temporary editor...

Might make it easier around the logic of maintaining when a new preview editor was opened or not. As well as the issue Im having when previewing in the preview editor, where the new files seem to be opened at the final line, vs. the top of file (they were not previously opened.)

If you did not have a preview editor open and the eager preview display opened an editor, then when cancelling, Im not certain how rest the editor group's state of active/preview editors.

[bpasero]

Whatever we end up doing, you cannot open a "preview editor", it can only be the file imho. I think in order to restore the previous state you probably have to capture it and restore it.

As for opening on first line, you can pass options for the open to have it open at line/col 1. it is interesting if that is the desired behaviour though.

[wprater]

Maybe my nomenclature is a bit off. I believe the current PR follows suit to the UX meetings notes. However, I would prefer we not allow any side effect when cancelling out of a quick open widget. If you agree, I need to determine if a new preview editor was opened when not one presently. If there was not one open, I need to be sure to close the preview editor that was created to preview the focused items in the tree. I'll look into that again tomorrow.

I don't desire to have them open on the first line/col, unless the file was not already present in an editor buffer. If I continually swap the preview editors, I was seeing many of my files loaded into the preview on the last line. The other files editors that are selected seem to work great!

[bpasero]

Ok I think I was confused by terms here. We agree on this behaviour:

• editors open when you navigate through the list
• if not yet opened in the group: they open as preview editors (not pinned) no matter what the user has configured to prevent accumulation of many editors
• otherwise they get focussed in the group
• they open on whatever line/col they used to be
• if there was no preview editor opened, the preview editor closes upon cancel
• if there was a preview editor, it gets restored upon cancel

[jespertheend]

It also doesn't show file icons in front of the results. I've submitted Cmacu/gotoanything#8 and Cmacu/gotoanything#9

[Cmacu]

Not exactly, it messes up searching with multiple words, e.g. if I have a file path c:/fruits/bananas/File.js searching with "bananas file" doesn't return results. Without the plugin it does.

It also doesn't show file icons in front of the results. I've submitted Cmacu/gotoanything#8 and Cmacu/gotoanything#9

Got it. I can resolve both of these over the weekend.

[TylerLeonhardt]

I feel like there's prior art here in the suggest widget:

[Aknc34]

gt

[dpidan]

I feel like there's prior art here in the suggest widget:

@TylerLeonhardt, Which dialog is that? It looks like a different dialog than the "quick open, go to file" (Crtl/CMD-p) which the OP seems to indicate in step 2:

2. Type a file name that returns several results

[jespertheend]

@dpidan I think the screenshot is referring to one of VSCode apis.
Basically if you press the right arrow with one of the files selected from quick open, it opens the file without closing the quick open dialog.
The only issue is that those files are opened permanently, so pressing the right arrow key subsequently on different files will just open a whole bunch of tabs, rather than replacing the previous editor.

[TylerLeonhardt]

@dpidan it's Intellisense in an editor... that has items, with additional context, and is keyboard driven.

[popadicbranislav]

While we wait for this feature, this extension FindItFaster does a pretty good job. It would be great if we get this built-in.

[codercodingthecode]

7 years later and counting ⏳ 😄

[Tantol]

While we wait for this feature, this extension FindItFaster does a pretty good job. It would be great if we get this built-in.

It will be amazing to have fzf with that preview build in to VsCode.

[lakshits11]

Dear Diary,
Its been December 2023. This feature is not implemented in VS Code. I will share more updates later.

:(

[martindrzka]

I'd pay for that feature. I really miss it.

[jbrodriguez]

FindIt Faster is quite good, it creates a new terminal in order to run rg/fzf/bat ... not quite the experience of a floating pane, like telescope.nvim, but it's quite good

thinking about it, i don't think vscode has centered floating panes, they all are attached to the top (such as the control panel)

[h0jeZvgoxFepBQ2C]

This feature is missing so much... PLEEEEESEEE

[joshmu]

I made a little extension 🫧 Periscope last year to give me an experience as close as possible whilst constrained by the existing vscode UI primitives.

It's evolved a bit to lean in to ripgrep but its remained my daily driver for grepping across the workspace.

Might be useful to some of you! ✌️

[macintacos]

@joshmu this kinda looks like the built-in "Quick Search" feature that VSCode has been iterating on for the past few releases, no? https://code.visualstudio.com/updates/v1_88#_quick-search-improvements

[jbrodriguez]

@joshmu this kinda looks like the built-in "Quick Search" feature that VSCode has been iterating on for the past few releases, no? https://code.visualstudio.com/updates/v1_88#_quick-search-improvements

however, there's no quick preview, i would guess it's because of the limitations with the vscode ui primitives, as @joshmu mentioned

that telescope.nvim ui is wicked, i'm seriously considering nvim

[macintacos]

@jbrodriguez not sure what you mean. As you arrow-through the results using VSCode's Quick Search, the currently-focused editor shows you a preview of that result in the file where it exists. Seems the same as the video in the extension I was replying to.

[jbrodriguez]

you're right, yes, not as straightforward, but does the job

[joshmu]

@macintacos the Quick Search (experimental) is similar to Periscope in regards to file previews as you navigate across results. The biggest difference would be that Periscope provides access to more of ripgrep. eg: pattern matching, file type & sub folder filtering, etc. You can personalise this to your needs and create abbreviations for your common searches.

If there is no interest in those type of advanced grep features then Quick Search would be sufficient

[h0jeZvgoxFepBQ2C]

@macintacos but the quicksearch feature which you mention, does not work when you go to "open file" search dialogue or? Just for full text seach, not for file search.

[macintacos]

@h0jeZvgoxFepBQ2C right. I wasn't saying that that feature in VSCode takes care of this issue. I was just saying that that feature is very similar to the Periscope extension that was linked to earlier in the thread.

I don't think that the issue described in the original description is "solved", by any means.

[musjj]

Would love to have this feature in the editor picker (when you press Ctrl+Tab) too.

[LucianCrainic]

Any news from the dev team on this ? A built in telescope in vscode would make the programming experience soo much better...