Open drew-wallace opened 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.
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.
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.
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
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. :)
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)
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?
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.
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.
Also, Sublime will put focus on an open tab if what you have selected in Quick View is already open.
yeah, see my PR. these behaviors are implemented. :)
@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.
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.
@wprater I do not understand why you would want to open a temporary editor...
@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.
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.
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!
Ok I think I was confused by terms here. We agree on this behaviour:
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?
@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.
Updated design notes above. Thanks :)
@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.
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
I'm interested too because this feature in Sublime is OP, we definitely need this in VS Code!!!
Unfortunately it seems like there are some technical issues blocking this. See this comment here: https://github.com/Microsoft/vscode/issues/12892#issuecomment-286149590
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!
@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?
Can we just write a simple script that will push right arrow key when scrolling in cmd+P?
One of the single most missed features from Sublime :(
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?
Any news? Trying to switch from Sublime to VS Code and I miss this feature a lot.
I need this so badly!
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
@mmcintyre123 Thanks. I will look into ways to improve the performance and add other features this weekend. Contributions are welcome.
I'd also very much like this feature!
What is the issue here? This is a show stopper for us, any plan to release this functionality?
I surprised that vscode does not support it....
Yes, Sublime Text has it and it's awesome. Any news on this?
Yes, Sublime Text has it and it's awesome. Any news on this?
+1
Is there an open PR for this? I would like to contribute if possible
Yes, Sublime Text has it and it's awesome. Any news on this?
+1
For now, I'd just go for https://marketplace.visualstudio.com/items?itemName=Cmacu.gotoanything Does exactly this :)
What's the status??? This feature was a major performance enhancer for me while playing with VIM.
Things I miss in quick open after switching to VSC compared to Sublime Text:
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.
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
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.
I feel like there's prior art here in the suggest widget:
gt
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:
- Type a file name that returns several results
Steps to Reproduce: