Feature: Vim navigation for the file explorer
In Onivim 1, we had vim-style keybindings for the file explorer. In this model, the file explorer behaved as another window split, in that you could <C-w>h over to it.
Once in the explorer split, you could use h/j/k/l to navigate along with various other vim bindings. In addition, we also were able to delete (with d) and yank (with y) - and even u undo.
This was actually really nice! But there were two problems:
-
The
dkey was too easy to hit. It as easy to start typing, not realize you're focused in the file explorer, and accidentally delete a file. I think, if we bring this behavior forward, we need to find a UX that is more deliberate for deletion, yanking, pasting, and undoing. -
We never implemented search for it (
/). I think a useful model would be search-as-a-filter in this view, but open to ideas.
Nerdtree has the menu you have to open before you can delete files and then prompts you if you are sure. So if your cursor was over a file you would hit m to open the menu, d to delete, and then it would prompt you y/N to verify.
For me the deal breaker on switching from vim to VS Code was how slow I felt not being able to use Nerdtree style controls. Being able to open splits/tabs with a key press is pretty handy (same with ctrl+p). Also having the option to rebind <C-w>h to ctrl + h (or any of the directions) would be awesome.
edit: had to fix <C-w> not showing
Cool, thanks for the feedback @ImCesar !
Nerdtree has the menu you have to open before you can delete files and then prompts you if you are sure. So if your cursor was over a file you would hit m to open the menu, d to delete, and then it would prompt you y/N to verify.
I was mostly an Ex user so I wasn't familiar with this - makes sense to check it out. Lots of thought went into though. Sounds better than our paradigm in Onivim 1, since there is less chance for an accidental deletion of a file.
For me the deal breaker on switching from vim to VS Code was how slow I felt not being able to use Nerdtree style controls.
I can relate to this! 😎 I missed being able to access everything from the keyboard.
Also having the option to rebind h to ctrl + h (or any of the directions) would be awesome.
I agree with this 100%, maybe this is another issue/feature request but it is my #1 reason for not switching over to some non-vim editor.
These days I do most of my file browsing with FZF (fuzzy finding by either file name or file content), and whenever I need directory tree navigation, I just open up ranger, which takes over the entire pane and acts like a "open file in current tab" dialogue.
Ranger's three column layout would probably not map well to a directory tree sidebar (even if vertically oriented), but I find its key bindings to be both easy to remember and very difficult to type by accident (I don't think I've ever done a destructive operation by accident, despite using it for 99% of my file browsing in general).
Not saying to scrap the sidebar, or course (even though I would prefer a single column Ranger-esque sidebar to a tree) - I just think Ranger is the gold standard for intuitive vim-like graphical file browsing, and would be a good example to look to for inspiration, if you're not already aware of it.
I very much want to be able to enter, manipulate and leave the explorer using standard vim shortcuts like <CTR-W>-H to enter and <CTR-W>-L to leave. I think the solution would be to add a default navigation mode to that view. In that mode, destructive normal mode commands like dd would be disabled but non-destructive normal mode commands like 5j would not be disabled. Then there is a shortcut to enter normal mode.
It'd be nice to start implementing this! Like #592 , this is a huge blocker for users coming from Vim.
I think we could start by just having basic keyboard navigation for the explorer and location list view, behavior like:
- When pressing
<C-w>h(move one window left) in the left most editor, the focus will switch over to the explorer (or active sidebar pane). If the sidebar is not opened, it will be opened. - When pressing
<C-w>h(move one window left) in the sidebar / explorer, the focus will switch over to the activity bar. - When pressing
<C-w>j(move one window down) from either the activity bar, explorer, or bottom-most editor, the focus will switch over to the 'pane' with search, find-all-files, diagnostics, etc. The last active pane will be open.
When each of these have 'focus', we can just keyboard shortcuts to navigate through them. When an element has focus, we should draw a border around the element - colored to the current mode.
'Tier 1' interactions would be:
- Up arrow to move upwards
- Down arrow to move downards
- k to move upwards
- j to move downwards
- enter to select (either expand a folder, or open a file in an editor)
'Tier 2' interactions would be:
ggto move to the topGto move to the bottom- number +
j/kto move X items up/down
'Tier 3' interactions would include:
- Search (
/,?) - Viewport management (
zz,zb,zt)
To start - just having the Tier 1 interactions + the infrastructure to move keyboard focus to these other elements will be a big step forward.
An idea I had that will keep us open to allowing Vim to handle some of this input is to have an abstraction, like:
let%hook () = Hooks.focusInput(~hasFocus=true, ~onUnhandledInput={(key) => {
// This method gets called when a key is passed, but was not handled by any of the bindings
//
});
Just some brainstorming - this is a huge gap in our story today. Is this something you'd be interested in, @glennsl ? You've done some work with the input management so you might have other ideas here 👍
Looking at this right now. Seems like window movement will need some refactoring of the WindowManager and how VimStoreConnector handles the movement events.
I don't use nerdtree all that often but I would like to chime in that its commands are very useful in regards to how it handles move/copy/open/delete. Specifically I appreciate the way it handles opening in a split or a tab etc.
The commands are pretty simple to grok I feel.
A prompt to confirm file deletion would be great, I've fat fingered it a couple times already.
I totally agree with ImCesar. The dealbreaker for me as far as VsCode is concerned is exactly not being able to use nerdtree like navigation. The panel in vscode. is another area which doesn't acts like another vim hsplit and so I have to use some other keybindings than those I use for navigating the vim windows. In my mind this breaks the intutiveness of vim navigation and acts as a real deal braker.
When I started trying Oni 2 on a project, what I found most wanting was better file explorer. This lead me to explorer what I would like as an ideal interaction (as a VS Code / Sublime fan), which ended up as a blog post about Defx - http://eed3si9n.com/defx

In addition to k j to navigate, and / to search, I often click around to expand the tree and preview files, which I've mapped to <CR> here.
Also being able to make new files, rename them etc would also be great.