Improve the custom completion menu

[lenormf]

Hi,

The window that pops up when a custom completion backend is triggered could be improve, in order to make it look more like the regular completion menu:

• the docstring seems to be displayed alongside of the actual completion entry, which looks weird, I think it should be embedded into the completion window
• the docstrings for all candidates should be displayed, not just the one for the currently selected candidate
• the docstring is always displayed next to the first candidate
• the pop up is sometimes only as large as the text it replaces (when there's only one candidate), which makes it hard sometimes to see that the completion has a candidate to propose

Thanks.

[mawww]

You 3 first points are easy to fix: dont put that info in the docstring, but in the menu entry text.

I think the current behaviour is correct, the docstring is for big documentation text, so we can only display one docstring at a time. Single line additional documentation can be just put in the menu entry.

For the last point, if the menu contains some additional info, the problem goes away.

[lenormf]

I thought markup didn't work in those windows, but they do, so it's all good now.

[mawww]

Yeah, at some point I'd like to have markup work fine in the info windows as well.

[casimir]

@mawww me too

Another thing I'd like is a way to provide complementary information in menus, with a different face and right aligned. Kind of like the file path when completing commands in kak files. That would be useful to add semantic information like symbol type or signature. I tried to emulate it in racer.kak by using the dim attribute but it's not working in all terminal and that's more work when coding the binding. You can see it in the screenshot above btw.

[danr]

Since the menu info can contain code snippets (like in your example above @casimir) we might want to be able to apply highlighters, too. We shouldn't have to reimplement syntax highlighting yielding markup.

[mawww]

Using the highlighting system on non buffers is going to be pretty hard, and a bit overkill for what we are trying to do here, I'd be more leaning towards a light markup system.

[casimir]

There 2 good points here:

• the info should not visually interfere too much with the buffer
• it can contains complex text that profits from rich text markup

I think using "monochrome" faces are enough by playing with "weight" attributes (bold, italic, underlined). We could reuse asciidoc markup for emphasize and strong text as an experiment and see if we need more.