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

Feature: Vim navigation for the file explorer #528

Open
bryphe opened this issue Aug 1, 2019 · 11 comments
Open

Feature: Vim navigation for the file explorer #528

bryphe opened this issue Aug 1, 2019 · 11 comments
Labels
A-file-explorer Area: File explorer enhancement New feature or request

Comments

@bryphe
Copy link
Member

bryphe commented Aug 1, 2019

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 d key 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.

@bryphe bryphe added the enhancement New feature or request label Aug 1, 2019
@ImCesar
Copy link

ImCesar commented Aug 1, 2019

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

@bryphe
Copy link
Member Author

bryphe commented Aug 1, 2019

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.

@jordanjones98
Copy link

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.

@nsmmrs
Copy link

nsmmrs commented Aug 2, 2019

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.

@snoblenet
Copy link

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.

@glennsl glennsl added the A-file-explorer Area: File explorer label Nov 18, 2019
@bryphe
Copy link
Member Author

bryphe commented Dec 15, 2019

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:

  • gg to move to the top
  • G to move to the bottom
  • number + j/k to 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 👍

@glennsl
Copy link
Member

glennsl commented Dec 15, 2019

Looking at this right now. Seems like window movement will need some refactoring of the WindowManager and how VimStoreConnector handles the movement events.

@williamtstanley
Copy link

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.

@opeik
Copy link

opeik commented Apr 28, 2020

A prompt to confirm file deletion would be great, I've fat fingered it a couple times already.

@gordonrust
Copy link

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.

@eed3si9n
Copy link

eed3si9n commented Jul 9, 2020

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

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.

bryphe added a commit that referenced this issue Sep 7, 2020
__Issue:__ The toggle-problems-pane command (bound to Control+Shift+M/Command+Shift+M) wasn't working. The command and key-binding had no effect.

__Defect:__ The 'workbench.actions.view.problems' command wasn't actually wired up to our action.

__Fix:__ 
- Move the 'workbench.actions.view.problems' to a contributed command from the Pane feature
- Move the Control+Shift+M / Command+Shift+M bindings to contributed keybindings from the Pane feature
- Wire up the logic for showing / hiding the problems pane.

Fixes #2408 - still need to wire up vim-style navigation to it, though (in the spirit for #528)
bryphe added a commit that referenced this issue Sep 9, 2020
In starting to work on #528 - vim navigation for the file explorer (and other bits of UI, like search, SCM, etc) - there's some preliminary work that needs to happen. In particular, we need to refine our concept of 'Focus' - for example, we currently have 'Explorer' as a focus state, but as we break down #528 and look at features like #1785 (directory explorers) - we need to refine this. In particular, there could multiple 'explorers' in the view, and the focus might need some state along with - like the current selected item, information about the viewport (for `zz`, etc).

We'll need to 'fractalize' our focus state - we'll keep track of sort of the high-level place we have focus - for example, the `Sidebar`, and then from there, the `Sidebar` can route focus operations, like text-input and paste, to the appropriate piece, which can then delegate it further (for example, for search - one focus state will be input focus, and another will be navigating the search results). So just like we have a 'fractal' model for state - we'll need a 'fractal' model for focus to handle these cases.

In addition, a common request I get (mentioned in #1914, and comes up a lot in e-mail) is that the search behavior right now is confusing - all other buttons in the sidebar change the sidebar stop, but the search one opens up an extra pane. Since we can now resize the search pane, and it will simplify the focus-work described above (it would otherwise be a special case), figured it was a good to move it. The UX should still be improved - with the default sidebar size, it's difficult to interpret the results.

__TODO:__
- [x] Fix context menu behavior in new model - there are some cases where it stays open
- [x] Fix default focus for search / SCM / extensions
bryphe added a commit that referenced this issue Sep 9, 2020
…2427)

This is some more plumbing to help streamline the focus management for the sidebar and interior panes, towards #528 .

This also adds a simple visualization to help debug input - right now, it just shows context keys, but could be useful for bubbling up more information about key presses (scan codes, etc) - to help debug some of the input-remapping issues. In addition, it could help us view the available key bindings in preparation for something like #756 visualization of available keys.
bryphe added a commit that referenced this issue Sep 11, 2020
…fixes (#2433)

This is more groundwork being laid to support #528 , which requires us to refine our focus management story. This enables features to conditional expose context keys (which may be from nested items - like the sidebar exposing `textInputFocus` when an input control has focus in a sidebar item...)

This moves `InputText` to a component - a rich component that exposes context keys, potentially keybindings, subscriptions, etc. I'll follow this same model for some additional rich components I'll be adding to support #528 

I started a debug view for input / context keys in #2427 , it's ugly right now - but it shows the `textInputFocus` key being set as expected in various scenarios:

![2020-09-10 15 32 01](https://user-images.githubusercontent.com/13532591/92817678-aef46280-f37b-11ea-82d7-fb5c4046c203.gif)

This fixes the `textInputFocus` part of #2428 , and requires a revery fix for drop-shadow to give more emphasis around text-inputs having focus: revery-ui/revery#999
bryphe added a commit that referenced this issue Sep 11, 2020
More work on the path for #528 - this allows UI components outside the editor text surface (like sidebar panes!) to opt-in to vim-style window navigation. I envision using this to navigate between pseudo-splits in the UI - for example, in search, to jump between the search text box and the results list:

![2020-09-11 09 13 39](https://user-images.githubusercontent.com/13532591/92949104-5ec6e000-f40f-11ea-8db2-69f4e7ac59c8.gif)

This lets features opt-in to handling window navigation in their own way, and then if they can't handle it (ie, it's at the border) - it would bubble back up to be handled by our layout system.

This doesn't implement list navigation yet (ie, the search results aren't actually navigable) - that's the next step.
bryphe added a commit that referenced this issue Sep 15, 2020
More groundwork on the path to #528 - this is some refactoring to support changing the initial load population strategy for the file explorer, which is blocking moving the explorer to its own self-contained feature.

In addition, this moves the file population story to use libuv - and importantly, not block on File I/O. Previously, we were using `Lwt.main_run` to block and populate the directory info synchronously (in addition, we were also traversing a single layer deep inside each folder, which isn't necessary for the initial population). This is actually one bottleneck on Windows start time, at least on my machine (related to #523 ). Removing this blocking is also important for moving to subscriptions, so that we can have predictable performance and running the subscription can be lightweight.
bryphe added a commit that referenced this issue Sep 17, 2020
This is to help support #1785 , by extracting the file-explorer to a stand-alone, modular feature, as well as making it easier to hook up to some of the incoming focus pieces for vim-style navigation (#528).
bryphe added a commit that referenced this issue Sep 17, 2020
This wires up vim-style window navigation to move across SCM subsections:

![2020-09-16 11 56 42](https://user-images.githubusercontent.com/13532591/93381304-50186880-f815-11ea-9ba3-37a7305ed047.gif)

More work on the path to #528 for vim-style navigation across all our UI.
bryphe added a commit that referenced this issue Sep 19, 2020
This is another step towards #528 - this creates a vim-navigable list component to be reused across portions of our UI.

In this PR, it's hooked up to search:
![2020-09-18 14 23 00](https://user-images.githubusercontent.com/13532591/93646232-aecb1700-f9ba-11ea-8fce-dfa7dd04cef2.gif)

__TODO - Blocking check-in:__ 
- [x] Fix diagnostics pane (requires #2466, #2478 )
- [x] Remove 'LocationList', which is replaced by the vim-navigable list + `LocationListItem`

Next steps:
- Hook up the vim-navigable-list to SCM
- Hook up the vim-navigable-list to Extensions
- Hook up the vim-navigable-list to Notifications (requires #2466)
- Create a vim-navigable-tree, to be used with the file explorer - and can address #528 
- Hook up search `/` / `?`
- Improve the UX of the search pane, so that the results are more visible - it's not very useful in the current form.
bryphe added a commit that referenced this issue Sep 22, 2020
More work on the path to #528 - this expands our vim-navigable-list to handle trees, too.

This PR adds a navigable-tree component, adds the concept of a tree view model (a flattened array of tree nodes, more amenable to the index-based operations we need for vim-style nav), and hooks up to search and diagnostics, to improve the UX (aka, make search a little more useful...):

![2020-09-21 14 32 30](https://user-images.githubusercontent.com/13532591/93827897-1aadb980-fc1f-11ea-80a3-750692ef9071.gif)

This lays the scaffolding to actually address #528 - next step will be to update the file explorer model to match up with the `Component_VimTree`. Getting closer! Will also be useful to finally finish #1181 and potentially hook up document symbols in the explorer.

__TODO (blocking check-in):__
- [x] Fix warnings / remove unused code
- [x] UX: Fix hover / focus background (should cover entire row)
- [x] Diagnostic: Add line number back to result
- [x] Wire up selection - this was pulled out temporarily
- [x] Wire up expand / collapse

__Next steps:__
- Handle scroll commands (Control+D, Control+E, etc)
- Implement search functionality across vimlist/vimtree
- Hook up to file explorer
bryphe added a commit that referenced this issue Sep 24, 2020
…er (#2502)

This brings in the the vim-navigable-tree introduced in #2492 , and wires it up to the file explorer:

![2020-09-23 12 32 08](https://user-images.githubusercontent.com/13532591/94060762-51a7da80-fd99-11ea-9a89-ea22e074595e.gif)

This supports some initial vim-style navigation, like j/k/zz/zb/zt. 

There are a few additional gestures I'd like to support, to be able to resolve (soon) #528 :
- Implement a search (hook up `/`, `?`, `n`, `N`) experience
- Implement cut/copy/paste (`yy`, `dd`, `pp`).
bryphe added a commit that referenced this issue Sep 30, 2020
Following from #2502, and working towards #528, this adds `/` & `?` search functionality for the explorer, search results, and diagnostics:

![2020-09-28 15 53 54](https://user-images.githubusercontent.com/13532591/94494102-2eb76500-01a3-11eb-910c-df1cdac155c7.gif)

__TODO:__
- [x] When the search query changes, focus the next match.
- [x] Tweak theme colors - the 'active' background is a bit intense for the search bar, and the foreground search icon is drowned out
- [x] Add additional 'selection' indication - in some themes, it's hard to differentiate search results vs selection
 
__Additional work:__
- Set up `yy` (copy), `dd` (cut), and `p` gestures for the vim list, and support in the file explorer
- Set up `o` and `O` gestures in file explorer to insert a new file
- Visual mode primitives - `v`/`V` to switch to visual mode for multi-selection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-file-explorer Area: File explorer enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

10 participants