search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.87k stars 29.51k forks source link

Show quick open results as preview while navigating through them #8939

Open drew-wallace opened 8 years ago

drew-wallace commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

Bold = addition Strikethrough = deletion

smuuf commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

wprater commented 8 years ago

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

bpasero commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

wprater commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

wprater commented 8 years ago

thanks for outlining these.

I have these all complete in the PR with exception of comments below:

if there was no preview editor opened, the preview editor closes upon cancel

need to determine best way to achieve this functionality.

also, can you edit your list to include a note about history? I want to be sure Im not including history events. there are two types, from what I can tell: handleEditorEventInStack and handleEditorEventInHistory. Do we need stop inclusion in both, or just the stacks?

bpasero commented 8 years ago

@wprater IEditorGroupService.getStacksModel() gives you complete access about what is going on in the editor stacks world (1 stack contains 3 groups side by side of N editor tabs). I think the best is to just store the current preview editor before doing the magic and then restore either the previous one on cancel or close the opened one if there was no preview editor before.

Yes you are quite right that these are the two methods that need to ignore the preview editors. The former is a stack of editors that you can go back and forward via the Go menu and the latter is the editor history that is persisted across restarts and accessible from Cmd+P. As you can see there is already a boolean blockStackChanges for the stack and we need to have a new method that flips another boolean for the duration of the previewing that also blocks changes to history imho.

bgashler1 commented 8 years ago

Updated design notes above. Thanks :)

ghost commented 6 years ago

@bpasero @roblourens Right now if we use CMD + P with right arrow key it will open file, but without preview mode. So basically if we improve right arrow key in file navigation to open file in preview mode this feature will be done. Of course it will be a little bit different from ST 3, because you see file content simultaneously while navigating.

aaronmw commented 6 years ago

What's happening with this feature? It looks like it's been discussed since 2016 but I'm not seeing it in the latest VS Code, even with workbench.editor.enablePreview and workbench.editor.enablePreviewFromQuickOpen set to true

ghost commented 6 years ago

I'm interested too because this feature in Sublime is OP, we definitely need this in VS Code!!!

stevencl commented 6 years ago

Unfortunately it seems like there are some technical issues blocking this. See this comment here: https://github.com/Microsoft/vscode/issues/12892#issuecomment-286149590

aaronmw commented 6 years ago

Hmm. Are they letting perfection be the enemy of good? It looks like it's possible to do, but just not in the "ideal" manner quite yet. A mediocre stop-gap solution would be better than nothing in the interim. Granted, this is all over my head so maybe I've misunderstood and they're blocked from even a mediocre solution? There are a lot of threads on the issue so it's hard to keep things straight...

Looking forward to some kind of solution to it, one day!

redbar0n commented 6 years ago

@stevencl @bpasero The issues mentioned in #12892 (comment) should not be a blocker. It could simply just work like preview mode currently does when selecting any new file from the file explorer. It will open a preview tab, and if selecting another file, then the preview tab name and content changes. It's not necessary to augment the core workbench UI with a whole new way of viewing files without any visible tab.

Wouldn't this be easy enough to implement if reusing the preview mode from the file explorer?

pycckuu commented 6 years ago

Can we just write a simple script that will push right arrow key when scrolling in cmd+P?

Frexuz commented 6 years ago

One of the single most missed features from Sublime :(

ZYinMD commented 6 years ago

I submitted #60822 to request a feature to immediately switch tabs when pressing Ctrl-Tab (as opposed to switching when Ctrl is released), but it was closed for being a duplicate of this one.

I don't see why it's a duplicate. I mean it's sort of related, but that one was much easier to implement, because that one doesn't require showing a file list (with or without the list are both fine). Maybe they're planning something big?

guisehn commented 5 years ago

Any news? Trying to switch from Sublime to VS Code and I miss this feature a lot.

yansern commented 5 years ago

I need this so badly!

mmcintyre123 commented 4 years ago

There is a very nice extension that has begun to implement this functionality. It could use some improvement if anyone has the time to contribute (and if the author is accepting contributions of course).

https://marketplace.visualstudio.com/items?itemName=Cmacu.gotoanything https://github.com/Cmacu/gotoanything

Cmacu commented 4 years ago

@mmcintyre123 Thanks. I will look into ways to improve the performance and add other features this weekend. Contributions are welcome.

ilyakamens commented 4 years ago

I'd also very much like this feature!

vinceprofeta commented 4 years ago

What is the issue here? This is a show stopper for us, any plan to release this functionality?

indigoram89old commented 3 years ago

I surprised that vscode does not support it....

aPinix commented 3 years ago

Yes, Sublime Text has it and it's awesome. Any news on this?

swist666 commented 3 years ago

Yes, Sublime Text has it and it's awesome. Any news on this?

+1

outdoteth commented 3 years ago

Is there an open PR for this? I would like to contribute if possible

r-moore commented 3 years ago

Yes, Sublime Text has it and it's awesome. Any news on this?

+1

rogiervandenberg commented 2 years ago

For now, I'd just go for https://marketplace.visualstudio.com/items?itemName=Cmacu.gotoanything Does exactly this :)

remainstheday commented 2 years ago

68747470733a2f2f692e696d6775722e636f6d2f5454546a6136742e676966 What's the status??? This feature was a major performance enhancer for me while playing with VIM.

trebor86 commented 2 years ago

Things I miss in quick open after switching to VSC compared to Sublime Text:

trebor86 commented 2 years ago

For now, I'd just go for https://marketplace.visualstudio.com/items?itemName=Cmacu.gotoanything Does exactly this :)

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.

jespertheend commented 2 years ago

It also doesn't show file icons in front of the results. I've submitted https://github.com/Cmacu/gotoanything/issues/8 and https://github.com/Cmacu/gotoanything/issues/9

Cmacu commented 2 years ago

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 commented 1 year ago

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

Aknc34 commented 1 year ago

gt

dpidan commented 1 year ago

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:

  1. Type a file name that returns several results