[WIP] Externalize CommandLine

[ghost]

Shamelessly taken from @Bretley, this merge takes his code and makes it again compatible with master. Quoting @bryphe from #1121:

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'?

That's what I'd like to do now. If there are any additional pointers on how I should continue, please let me know.

[bryphe]

Thanks for all the help here, @samvv (and all your work too, @Bretley ) ! I just tried out the pull and it looks so cool... I can't wait for this to make it in 👍

One interesting thing here today is that Oni really has two 'command' experiences:

• The command palette - accessible via Control+Shift+P/Meta+Shift+P - this is more akin to the command menu in Atom/VSCode/Sublime Text/etc - it's different from : ex mode in that it's mostly oni-specific commands. This is Oni only, and exposes some options that don't make sense at all in neovim (like Open DevTools).
• The command line / wildmenu integration - which is the externalized : ex mode.

Long-term, it might make sense to combine them in some way - it's nice if there is a unified model. Part of the challenge is balancing the idea of bringing new users to vim (who come from Atom/Sublime/VSCode, and aren't familiar with the command line/ex mode), and also giving power-vim-users the same functionality they expect. But from that perspective, maybe it's okay to have a split - let the new users get their feet wet with the command palette, and let the veteran vimmers have the cmdline (with an improved UX!).

When I was thinking about the keybindings in the quote above - I was thinking more in terms of the command palette - I figured that's the first place a new user would go (and hopefully we can prompt them to get there w/ a better start screen experience!):

I'm actually not sure how it would work in the externalized cmdline/wildmenu - one thing we could potentially do is look to see if, as the user is typing, any key is bound to a particular command. For example, if I type :vsp, we could check the keymaps via the nvim_get_keymap msgpack call - and if there is a mapping associated with that, we could show the keys inline. That might be kind of cool. But I imagine if a user makes it to :, they already have at least some familiarity with Vim - so there may be less utility for it, as opposed to the command palette. Let me know what you think!

[ghost]

I actually quite like the idea of having all commands nicely packed in one place, so that when I forget one I can simply look it up (that's why I wanted this so badly). I actually thought of parsing the :command output so that one can even fuzzy find on command name (Neovim currently does not provide a means to list all available commands via RPC or eval, unfortunately). In that case, an exact match would get precedence over 'fuzzy found' ones, but if no exact match is available it would try to get one using fuzzy search.

I think I make this scenario work if you like it.

Edit: forgot to mention: that would imply only one pane (the command palette), as you suggested @bryphe

[bryphe]

I actually quite like the idea of having all commands nicely packed in one place, so that when I forget one I can simply look it up (that's why I wanted this so badly).

Cool, yes, if we can figure out a way to consolidate them in a common place, that would be great! I do think that having separate implementations - the command palette and the command line mode externalized - would be quicker to implement, and it would let us make an incremental step in that direction. But combine them up-front in a way that is intuitive, that's great.

I actually thought of parsing the :command output so that one can even fuzzy find on command name (Neovim currently does not provide a means to list all available commands via RPC or eval, unfortunately)

If we just bring in the static commands, we could potentially generate that offline (and come up with friendly names for some of the commands). We would need to find a way to get ex commands generated at runtime.

Edit: forgot to mention: that would imply only one pane (the command palette), as you suggested @bryphe

Would this mean we'd integrate the output from the ext_cmdline into the command palette? Or integrate the full set of commands a different way?

[ghost]

But combine them up-front in a way that is intuitive, that's great.

That's exactly my thought. 😄

Would this mean we'd integrate the output from the ext_cmdline into the command palette? Or integrate the full set of commands a different way?

Good question ... I'd say yes, if we really wanted to get a fluent interaction. Will not be as straightforward as it sounds, though ... on the other hand, it's almost weekend so I'll be having some time to experiment. Did you have something else in mind?

[bryphe]

Good question ... I'd say yes, if we really wanted to get a fluent interaction. Will not be as straightforward as it sounds, though ...

Right, agree with it not being straightforward - the menu might not be able to support the full set of interactions that the cmdline expects - like recursive / nested commands, etc. Another caveat (although I could be mistaken) is that the external cmdline wants control of the cursor position - whereas the menu input right now is basically just an uncontrolled input box. So there will be a few things that will need to be thought through.

There are two alternatives to combining: one is to surface everything via the command palette, and the other is to surface everything via the cmdline. The challenge with the first approach - everything via the command palette - is we definitely wouldn't have the full support of the capabilities of the existing command line, and we'd have to rationalize things like passing arguments. The challenge with the second approach - everything via the cmdline - is that we'd have to let Vim know about all the handlers that Oni has, and some discoverability is sacrificed (the fuzzy finders usually are verbose in terms of the command name + text, which I'm not sure how we'd replicate in the vim cmdline).

So I guess there's 4 options:

• Combine the external cmdline + existing command palette
• Move everything to the existing command palette
• Move everything to the external cmdline
• Implement them separately for now.

Did you have something else in mind?

Just the above options... I lean towards the 4th - implement separately - just because it seems the simplest today, and can satisfy both the novice user and experienced vim user scenarios. However, I am not an expert on the external cmdline and the full set of capabilities there - so I'm open to exploring any of the possibilities. Interested to see what you come up with! 👍 Thanks for your thinking around this, @samvv !

[akinsho]

@samvv @bryphe The majority of the work here seemed to be done so I had a quick look at fixing conflicts, and tweaking it to use styled components.

Unfortunately theres an issue with the cursor which is that as the event happens essentially separately from the input/output component so an input element for example doesn't have full cursor control, @Bretley @samvv not sure if either of you are still working on this or had any plans as to how to get round this?

Happy to leave this be if either of you are still working on it was just thinking to get the simplest implementation working since you've both done all the heavy lifting and then that can be iterated on in the future rather than see the work get buried in a sea of merge conflicts?

[bryphe]

@Bretley @samvv not sure if either of you are still working on this or had any plans as to how to get round this?

Yes, I was wondering the same thing about this! It seems like we might have to render the cursor, like we do for the NeovimEditor. But I wasn't sure (maybe we could reuse the Cursor.tsx component, but connect it to a different store).

Happy to leave this be if either of you are still working on it was just thinking to get the simplest implementation working since you've both done all the heavy lifting and then that can be iterated on in the future rather than see the work get buried in a sea of merge conflicts?

This is a great idea! We could bring it in behind an experimental flag - like experimental.commandLine.mode (similiar to how we have tabs.mode or completion.mode for other externalized features) - off by default. This will help us stay afloat over a sea of merge conflicts, and make it easier to get further contributions. 💯 It would be a bummer to not be able to merge this!

[bryphe]

I'll close this out, since there is a lot of progress in #1191! We can open a new PR for any additional functionality. Thanks all for the contributions here!