Oni: useExternalPopupMenu potentially not respected.

[jordwalke]

I wanted to try using Oni to test the general stability, but since I can't yet replace my plugins with Oni's default plugins, I have to create a trimmed down configuration (that uses Vim's internal popup menu for example). However, I think the useExternalPopupMenu setting isn't being respected. I'd like to just use Vim's internal completion menu for now because with my vim config, the externalized one jumps around too much (another issue I can investigate at some other time).

Here's my config:

const activate = (oni) => {
    console.log("config activated")

    // Input 
    //
    // Add input bindings here:
    //
    oni.input.bind("<c-enter>", () => console.log("Control+Enter was pressed"))

    //
    // Or remove the default bindings here by uncommenting the below line:
    //
    // oni.input.unbind("<c-p>")
};


module.exports = {
    "menu.caseSensitive": "smart",
    "editor.scrollBar.visible": false,
    "editor.cursorLine": false,
    "oni.useDefaultConfig": false,
    "debug.incrementalRenderRegions": false,
    "prototype.editor.backgroundOpacity": 1.0,
    "prototype.editor.backgroundImageUrl": "",
    "prototype.editor.backgroundImageSize": "cover",
    "experimental.autoClosingPairs.enabled": true,

    "prototype.editor.maxCellsToRender": 12000,

    "oni.useExternalPopupMenu" : false,
    "oni.loadInitVim": true,
    "oni.hideMenu": true,

    "editor.fontLigatures": false,
    "editor.linePadding": 1,
    "editor.fontSize": "14px",
    "tabs.mode": "buffers",
    "tabs.height": "2em",
    "editor.quickInfo.enabled": false,
    "editor.completions.enabled": false,
    "editor.errors.slideOnFocus": false,
    "editor.formatting.formatOnSwitchToNormalMode": false,
    "editor.fontFamily": "PragmataPro",
    "statusbar.enabled": false
}

[CrossR]

Yep, if you do a search for useExternalPopupMenu in the whole project, the only places it is used is in the Config definition and in the default config setup.

popupmenu_external which it should be setting is just hard coded to true at the moment, so this looks to have a very similar issue to #992, where there used to be an option for this and it has become unused.

Is true and false enough here again, or should there be more descriptive options / alternatives like no pop up at all?
Otherwise the PR for this should be pretty straight forward.

[bryphe]

Thanks for the investigation, @CrossR !

Yes, this seems similiar to the tab issue in #992 - I think we'd have a few options here:

• Use editor.completions.enabled and add 'native' as an option (like we have for tabs.mode - this would give us true | 'native' | false as options.
• Switch to editor.completions.mode like we have for tabs
• Hook up oni.useExternalPopupMenu again

IMO, editor.completions.mode isn't very clear, especially coming from Vim's world of omni-completion, keyword completion, etc..., so I'm leaning towards the first option: adding 'native' to editor.completions.enabled, as it is similiar to what we did for tabs - @CrossR @badosu does that seem reasonable?

[bryphe]

Oh and the jerkiness of our externalized popup menu is related to #895 - we position it based on the current cursor position (and some logic like measuring / deciding to open from top or bottom is based on that). This would work great... except the cursor intermittently moves to the command line to show messages (remnant of the terminal UI 😄 ). Externalizing it, via #908 , would address that particular issue.

[CrossR]

IMO, editor.completions.mode isn't very clear, especially coming from Vim's world of omni-completion, keyword completion, etc..., so I'm leaning towards the first option: adding 'native' to editor.completions.enabled, as it is similiar to what we did for tabs - @CrossR @badosu does that seem reasonable?

Seems reasonable to me, though I wonder if there is any other wording we could use instead of true/false values or perhaps a change in the option name? When I see booleans, I assume there is only 2 values to pick from, whereas here there would be 3.

Perhaps something like editor.completions.menuStyle? That would let you have oni, native and hidden/disabled?

[bryphe]

Makes sense to me, thanks for the suggestion @CrossR !

In that case, we should be consistent with tabs.mode - how about editor.completions.mode - with 'oni' | 'native' | 'hidden' as values? I think that's about as similar as we can get between the settings, and we'll now have an established pattern (like we could reuse for other externalized features, like having an editor.commandLine.mode/commandLine.mode configuration for #908)

[CrossR]

To give an update on this, the newly released version has editor.completions.mode, which if set to native, should default you back to the vim pop ups.

[CrossR]

This can probably be closed now, but the issue mentioned of

the externalized one jumps around too much (another issue I can investigate at some other time).

is now happening to me on the current release, or at least something similar.

I should probably take a video to show it better, but basically it takes maybe half a sec to highlight the option for some reason. In the image I'm on 2, but it isn't highlighted yet.

Probably worth separating out into a new ticket.

[bryphe]

is now happening to me on the current release, or at least something similar.

I see the issue you're talking about (if I use the vim completion). It looks like some sort of repaint issue, where the box-shadow is delaying being applied. If I switch to use background-color instead of box-shadow, it paints immediately... pretty bizarre!

Probably worth separating out into a new ticket.

That sounds good, then we can close this out!

[bryphe]

Closing this out to track remaining issues in #1265

[bryphe]

The jumpiness was addressed with #1268 , and @CrossR 's fix handles either Oni's completion (editor.completions.mode set to oni), Vim completion w/ externalized popupmenu (editor.completions.mode to set hidden), native Vim completion oni.completions.mode set to native.