Skip to content
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

requires too many keystrokes for the standard use-case #19

Open
grozan opened this issue Oct 11, 2020 · 2 comments · May be fixed by #24 or rbadapanda/vscode-file-browser#1
Open

requires too many keystrokes for the standard use-case #19

grozan opened this issue Oct 11, 2020 · 2 comments · May be fixed by #24 or rbadapanda/vscode-file-browser#1

Comments

@grozan
Copy link

grozan commented Oct 11, 2020

Hi,

I think the use-case number one for most people is to quickly switch between different exisiting files
It's nice to be able to create new files and folders, but I think most people use existing files most of the time

Let's say I'm in a folder with those files

foobar1
foobar2
foobaz1
foobaz2

What I'd expect, to speed up my workflow, would be that:

  • if I type bar, only the files/folders containing that string anywhere in their name are shown. The others disappear from the view as I type to narrow down my (fuzzy) search
  • if I press TAB, whatever file/folder which is selected right now is selected. I open it if it's a file, or I enter it if it's a folder
  • if I type the name of something which does not exist, then I press CTRL A to open the extra menu allowing me to create a file OR a folder call like that
  • if I press CTRL A while an item is selected, I get the extra menu allowing me to rename/delete that file or folder, depending on what is selected

Don't you think this would be a more fluid workflow?

Right now, if I want to quickly jump to another existing file, I have to make sure I type the beginning of the filename, cause otherwise pressing TAB is not going to autocomplete and open the first match.

In my example, I cannot just type z2 then TAB and have the foobaz2 file opened.
Instead, if I type z2 I have the option to create a file called z2 first (Again, I don't think it's the use-case number one to constantly create new files/folders). I then have to go down once, to select my file, and then press ENTER.

The list is reorganised, and the files containing z2 are at the top of the list, but the others are still there, which I find very confusing. Why not hiding them, as they are no match for z2?

would you consider changing the workflow, or to introduce new options to make "fast switching" faster, as well as "hide items that don't match" possible?

@matklad
Copy link

matklad commented Oct 19, 2020

Uhu, as a new user of the extension, I also find the the create action being default confusing:

image

I'd love to have an option to put the "Open as new file.." option to the bottom, or maybe remove it altogether in favor of something like "pressing ! or ctrl+enter creates the file"

But otherwise, it's a very lovely extension, thanks! I didn't even realize how much I miss helm :-)

rbadapanda added a commit to rbadapanda/vscode-file-browser that referenced this issue Nov 29, 2020
Fixes bodil#19

  * moved 'open as new file' to action menu.
  * The extension will be loaded after vsCode startsup.
@samaaron
Copy link

I'd love to have an option to put the "Open as new file.." option to the bottom, or maybe remove it altogether in favor of something like "pressing ! or ctrl+enter creates the file"

Agreed that (at least for me) creating new files isn't as common as opening existing files. Personally I imagined that "open as new file" is just fine at the top, but perhaps the 2nd item in the list (the best match for file open) should be selected as default. This would mean users would need to hit the up arrow and then return to create a file or just hit return to open a file - rather than the current behaviour which requires users to press down then return to open a file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants