Oni: Keyboard Accessibilty for non-Vim/Neovim features

[bryphe]

One major selling point for me in using Vim/Neovim is keyboard accessibility. In fact, the reason I started using Vim in the first place was because I had trouble coding on an airplane and hated touchpads ✈️ 😄

At the same time, Oni is exploring bringing in some modern, non-terminal UX features that are present in more modern IDEs. The log viewer in #365 is an example - some other examples might be a file browser, a git repo history browser, markdown preview, etc. I believe it is still important to preserve the keyboard accessibility of these features in a way that makes sense to Vim users.

I'd like to propose adding capabilities similiar to Vimium (https://github.com/philc/vimium) or cVim in the browser - these let you specify a specific hotkey, like f and jump to elements on the page.

The behavior could be as follows:

• Hotkey to trigger behavior: <Alt+s> for navigation with the current buffer/window/split, <Alt+Shift+s> for navigation across Oni
• Once the hotkey is triggered, we would show labels against all interactive elements, something like this:
  

This would make it easy to quickly navigate across various pieces of UI.

Some example use cases:

• Trigger a button in a sidebar menu
• Trigger a status bar item
• Open a markdown preview window, use this behavior to click a link
• Open a separate browser window, use this behavior to navigate

[justinmk]

I wonder what mechanism could be added in core nvim to help with this. E.g. for the examples of an embedded web browser, or a graphical file tree, one can ask: what do users want carried over to those components?

The most basic thing that stands out is key mappings. As I user I would want to be able to ctrl-w to the graphical window like any other text window, and have buffer-local mappings there.

These graphical windows could be backed by a special buffer type (or even just a blank, normal buffer with a name like [External] and filetype=extfoo). Then users can set up mappings using the typical approach, on a FileType event: au FileType extfoo nnoremap <buffer> a b. The external UI would probably need to ignore the cursor position reported by nvim in these buffers, but the external component still needs to know the user pressed something (j) that means "go down 1 unit".

What's the minimum needed from core nvim to support this somewhat elegantly for external UIs? Perhaps a new mode (and/or new "mapping namespace", e.g. :enoremap) is justified?

[jordwalke]

I would want these key bindings to integrate with the actual internal vim windows. For example in Atom, I have a binding to move to the left window or right window. It focuses either the split to the left or right but then it eventually focuses the file tree if that is the left most window. I would hope it possible to make the internal key mappings integrate well in a similar manner.

[bryphe]

With the latest work, we now have window navigation between windows / splits / sidebar pane (using the same mechanism, like <C-w>h, and we have a preliminary 'jump-to-elements' behavior with Control+G. So I'll close this out for now, but it does need further integration with some of the upcoming features (like the embedded browser) to be really useful!