-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve last value of Quick Open #49840
Comments
(Experimental duplicate detection) |
Previously opened files are shown in the recently opened section: Quick open history is covered by #18232 |
@mjbvz I think the point of this one in particular is to easily modify the last item you opened. In a number of javascript frameworks and in rails for example, the workflow to open files related files quickly. e.g. in the case of Ember, often you'll type something like In the case of Rails, I'd see similar usecases for opening a class and then easy opening the corresponding spec. So it's not so much about the "history" but quickly opening similar or related files. Please consider reopening. |
I have many files named after their feature, when refactoring a feature group I type a complicated fuzzy search to get them all in one quick open search, but then to get them all to show up again, I need to type it (and remember it) all over again. Of course it also helps if a user accidentally clicks the wrong result in the search. Quick open is a great file navigation experience (I rarely use the explorer), having a preselected (once you start typing it is replaced) last search term in it when you open it is such a no-brainer and such a big productivity boost. I also think that the last term shouldn't be hidden under another (history) keypress. Please consider reopening. |
Steps to Reproduce:
⌘P
⌘P
Does this issue occur when all extensions are disabled?: Yes/No
It would be great to preserve the last value of the Quick Open search field as I am usually searching for similarly named files when using Quick Open in quick succession.
refL #17163
The text was updated successfully, but these errors were encountered: