Feature: Extend command palette to include Vim commands

[bkd705]

Problem

The biggest problem I think most people have when trying to learn vim (my own personal experience included) is trying to figure out all the commands ranging from the basic movement (and of course the popular “how to exit vim”) all the way to veterans finding new commands that make their workflow faster.

Solution

OniVim has a command palette currently, but it only gives you basic menu options and plugin options. It would be awesome if we could expand this to include Vim commands and their respective keybindings. Similar to how VSCode’s works as shown below, you will get a title representing what the command does, and then also a display for the shortcut to run that command, allowing you to learn it and use it for the next time!

Example

Say I want to format a JavaScript document in Visual Studio Code,

Not only have I now run the command, but I also now know the keyboard command is Shift + Option + F.

Implementation Ideas

OniVim already has the command palette portion, the implementation of this would be extending that to pick up Vims keybindings and their respective commands, and mapping them out into a fuzzy searchable structure that would be quick and accurate.

Closing Comments

I believe this would be an awesome addition to OniVim, I personally am not a heavy user of it, but I think this would really push me harder to try it, as my personal biggest struggle with Vim is learning and memorizing all the commands, and having a popup that would both run the command and give me the hotkey would make the curve a lot less steep, and from what I understand thats a huge part of what OniVim is all about! :D

If this was to be a popular idea, and it is possible to implement, with some guidance I would be open to trying to tackle it!

[ghost]

Sounds very cool! One thing I am wondering is ... what to do with commands that accept arguments? I guess it is taking it a bridge too far to include that in the UI as well, a bit like QuickSilver does? Because I suspect there's no way to get information about the completion arguments, commands that want to integrate with the UI will have to register themselves a second time (that time with completion information for Oni). It's a bit redundant, because in theory the information is already right there. From the Neovim manual:

By default, the arguments of user defined commands do not undergo completion.
However, by specifying one or the other of the following attributes, argument
completion can be enabled:

-complete=augroup	autocmd groups
-complete=buffer	buffer names
-complete=behave	:behave suboptions
-complete=color		color schemes
-complete=command	Ex command (and arguments)
-complete=compiler	compilers
-complete=cscope	|:cscope| suboptions
-complete=dir		directory names
-complete=environment	environment variable names
-complete=event		autocommand events
-complete=expression	Vim expression
-complete=file		file and directory names
-complete=file_in_path	file and directory names in |'path'|
-complete=filetype	filetype names |'filetype'|
-complete=function	function name
-complete=help		help subjects
-complete=highlight	highlight groups
-complete=history	:history suboptions
-complete=locale	locale names (as output of locale -a)
-complete=mapping	mapping name
-complete=menu		menus
-complete=messages	|:messages| suboptions
-complete=option	options
-complete=packadd	optional package |pack-add| names
-complete=shellcmd	Shell command
-complete=sign		|:sign| suboptions
-complete=syntax	syntax file names |'syntax'|
-complete=syntime	|:syntime| suboptions
-complete=tag		tags
-complete=tag_listfiles	tags, file names are shown when CTRL-D is hit
-complete=user		user names
-complete=var		user variables
-complete=custom,{func} custom completion, defined via {func}
-complete=customlist,{func} custom completion, defined via {func}

[ghost]

Actually, since this is blocking my personal experience with Oni too, if it's OK I'd like to begin with this issue as my first of #1120.

[CrossR]

Actually, since this is blocking my personal experience with Oni too, if it's OK I'd like to begin with this issue as my first of #1120.

Might be worth checking in on #1072, which is working on Externalising the Neovim commandline and potentially the wildcard menu. There is also #635 which contains a bunch of ideas and thought on stuff like this, and the context of swapping between Oni Commands / Vim Command Line, though I think that PR is now being kept around just for the comments as they haven't the time to work on it anymore. Feels like something like this would fit within that sort of work.

But certainly sounds cool to me, I've been using Vim for like 5 years and I still find some things I didn't know about. Would be a good bridge between Oni vimtutor (#430), letting a user do the tutor, and then still have a quick reference point for details once actually using Oni/vim.

[bryphe]

Thanks @bkd705 - great write up!

Agreed, it would be a great way to lower the bar. We also have issues of discoverability with the built-in 'Oni' commands we have today - as @bkd705 mentioned, a common way people learn Atom/VSCode is to look through the command palette to see the key bindings. Unfortunately it's not as easy for Oni today.

A good first step on the Oni side would be to show our current set of keybindings in that command palette window. There would be a few things needed there (that could then be reused for the Vim commands):

• Adding the ability to show keys in the Menu - perhaps we could extend it with a custom React component? That code is in need of some love
• Having the ability to do a reverse query on the InputManager - be able to ask 'what keys do I have bound to this command'?

This would open the door to then extend it for Vim commands - which would be next level in terms of helping people learn Vim!

One question I had about the Vim commands - would we primarily show the : ex commands, or would we want to show things like Vim: Change in word with ciw? (Or even individual motion / operators) I'm envisioning the latter would likely be the most important in terms of getting users new to vim up-to-speed and productive.

[ghost]

@CrossR Thanks for the references. I'm having an idea that might solve part the integration, but I need to performs some tests first to see if it is not too crazy. 😄

One question I had about the Vim commands - would we primarily show the : ex commands, or would we want to show things like Vim: Change in word with ciw? (Or even individual motion / operators) I'm envisioning the latter would likely be the most important in terms of getting users new to vim up-to-speed and productive.

@bryphe That's exactly what is bothering me right now ... perhaps both, provided that it does not clutter the list too much?

[CrossR]

One question I had about the Vim commands - would we primarily show the : ex commands, or would we want to show things like Vim: Change in word with ciw? (Or even individual motion / operators) I'm envisioning the latter would likely be the most important in terms of getting users new to vim up-to-speed and productive.

If it is that style of command, I think a vim-sneak style UI would be beneficial. That helps teach about the different boundaries, so they see exactly what ciw will change, since I think for say my_variable_name it would change everything, where a user may think it would only change variable if they have that highlighted etc. If instead when they hover over Vim: Change in word, it highlights the area of effect, they get more feedback.
That said, it only works if the panel isn't covering the area affected.

Feels like a v2 of this though, rather than the initial implementation, and obviously a flag to disable for once a user has go to grips with it all.