UI - Integrate 'popupmenu_external' with completion

[bryphe]

Came about from discussion with #6 - there are some really cool UI integration points being added here: https://github.com/neovim/neovim/pull/5686

Initially, this PR has already been merged and is available - so integrating with the external popupmenu would be a good starting point.

[Bretley]

So I changed the args in guiattach from (80,40,true) to (80,40, {"rgb" : true, "popupmenu_external" : true})

as was suggested by the rpc doc you linked. What's weird is that the screen doesn't draw at all.

It still works, (as in connects to neovim) I edited and saved a file with no screen 💯

I'm not super familiar with the hierarchy of this repo and am still exploring, but if you have any guidance let me know; I'd like to learn :)

[bryphe]

Thanks for looking at this, @bert88sta !

Ah ya, unfortunately there's a bug with neovim/node-client that causes an issue with this.

Try starting from this branch: https://github.com/extr0py/oni/tree/extr0py/external-popup-menu

This commit specifically has the workaround I needed: https://github.com/extr0py/oni/commit/2d3e535eff2146fea529bae6a6e002c8b21c8ec1

[Bretley]

I don't know much about the principles of Typescript, i.e. what needs encapsulation and whatnot, so here's my question.

the popupmenu needs access to UI for completion and menu access. Do we move these popupmenu signals from "actions" to a diffferent type of event? it seems like you put all the other redraw options under actions, so I went with that, but short of bringing UI into Screen.ts there doesn't seem another way to do it.

[Bretley]

@extr0py: do we want to add a dispatch method to UI? As neovim grows, the level of UI control we have is only going to increase, and more of the on("action") (which I assume you want to maintain since all of the "action"s are used for redraw) are going to make calls to UI for popups. If not, just give me a general overview of what you'd think is a good way to implement.

[Bretley]

@extr0py

After reading some crash course node/electron/flux/redux materials, I realize now that the last comment made 0 sense in terms of design. I do actually have an important question for you though:

Do we handle completion completely externally, as in menu interactions will not interact back with vim? I think that it makes sense to allow things from vim to come into the list, but passing c-n back to vim for it to register the selections might get tricky if we ever run into the issue of vim and oni plugins fighting for space on the completions menu.

I think this is an important plan to come up with before ppopupmenu/completion work gets too in depth

[bryphe]

@bert88sta - that's awesome that you read through all that material! Really cool :)

Regarding handling the completion completely externally or not, that's a great question - that's really the crux of the challenge here. The design in my mind was to handle the completion completely externally, as you suggested, just to simplify. I think it will be hard to get right otherwise, especially with some of the different completeopts, and this will make all the completion scenarios cohesive - completion will behave the same whether the entry point was from VIM or from a UI plugin. Thanks for thinking about this!