-
Notifications
You must be signed in to change notification settings - Fork 283
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
Comments
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 edit: had to fix |
Cool, thanks for the feedback @ImCesar !
I was mostly an
I can relate to this! 😎 I missed being able to access everything from the keyboard. |
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'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 |
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 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:
'Tier 2' interactions would be:
'Tier 3' interactions would include:
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:
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 |
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. |
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 Also being able to make new files, rename them etc would also be great. |
__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)
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
…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.
…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
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.
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.
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.
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.
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
…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`).
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.
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 (withd
) and yank (withy
) - and evenu
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.The text was updated successfully, but these errors were encountered: