Plugins and (G)UI

[AljoschaMeyer]

Many editor plugins integrate with the UI of the editor. Examples inlude opening new panes (e.g a file-explorer plugin), adding a status bar, adding to a status bar, line gutter information, and so on. How would these sorts of plugins be handled in Xi? The following approaches are the obvious ones, but all of them have their problems.

• don't allow plugins to integrate with the UI
• only one Xi frontend
• each frontend defines its own API
  • plugins become frontend specific
  • fragmentation of plugin ecosystem and lots of duplication
• define a common frontend UI-API against which plugins are written and which is implemented by all frontends
  • API/protocol complexity explodes
  • might end up reinventing window managing, layout engines, etc.
  • clashes with the goal of integrating with the native environment
• include UI-API in Xi Core

The way Xi handles this might impact discussions such as #158.

[cmyr]

I've been thinking about this for a while, and I have some thoughts:

A goal of the project is to support a variety of frontends, but also to take advantage of native UI as much as possible. With this in mind, I think that specific UI idioms and implementations need to be left up to the front end, but standards can be described for many common plugin tasks.

Off the top of my head, I think standard message formats and names would work for autocompletion, status bar items, tooltips, and gutter items. In some of these cases, it might even make sense for a plugin to contain image assets.

By this I mean: a plugin which offers completion suggestions should return results in a standard format, and a front-end should present these results with whatever UI is appropriate.

I do think that there are potentially helpful plugins where this fails; these are cases where much of the real work is in designing the interface, or in doing drawing. It might be nice to have a minimap plugin, for instance, but this wouldn't make a ton of sense in xi-tui.

So my basic current thinking is that plugins should be implementation agnostic, should fail well, and that should be some thought to allowing platform-specific plugins.

Curious to see what others think. :)

[cmyr]

I've been thinking about this for a while, and I have some thoughts:

A goal of the project is to support a variety of frontends, but also to take advantage of native UI as much as possible. With this in mind, I think that specific UI idioms and implementations need to be left up to the front end, but standards can be described for many common plugin tasks.

Off the top of my head, I think standard message formats and names would work for autocompletion, status bar items, tooltips, and gutter items. In some of these cases, it might even make sense for a plugin to contain image assets.

By this I mean: a plugin which offers completion suggestions should return results in a standard format, and a front-end should present these results with whatever UI is appropriate.

I do think that there are potentially helpful plugins where this fails; these are cases where much of the real work is in designing the interface, or in doing drawing. It might be nice to have a minimap plugin, for instance, but this wouldn't make a ton of sense in xi-tui.

So my basic current thinking is that plugins should be implementation agnostic, should fail well, and that should be some thought to allowing platform-specific plugins.

Curious to see what others think. :)

[AljoschaMeyer]

A common frontend API seems to me like the most reasonable approach as well. In some sense, such an API would not even be specific to Xi. Instead, it would provide a general description of common text editor UI idioms, as well as a message format. Any text editor could decide to provide this API, even it is does not use the Xi core. Even better, it would be possible to write plugins for other editors which translate incoming messages into editor-native API calls. In the best case, this results in an easy way to write cross-editor plugins.

Here are some further issues that would need to be adressed if chosing this direction:

• API providers should be able to accept only a subset of the API
  • tempting to include a mechanism to query API conformance in the API itself (and possible make it the only required part of a conforming implementation)
• how much should this be tied to Xi, if at all?
  • some things might be more efficient if provided by the core, then again the core should not become bloated
• what gets included and what does not?
  • this comes down to a lot of case-by-case decisions, so some clearly stated overall criteria and/or guiding philosophy would be helpful
• how does Xi (or rather the various Xi frontends) handle everything that is out of scope of the API?

[AljoschaMeyer]

A common frontend API seems to me like the most reasonable approach as well. In some sense, such an API would not even be specific to Xi. Instead, it would provide a general description of common text editor UI idioms, as well as a message format. Any text editor could decide to provide this API, even it is does not use the Xi core. Even better, it would be possible to write plugins for other editors which translate incoming messages into editor-native API calls. In the best case, this results in an easy way to write cross-editor plugins.

Here are some further issues that would need to be adressed if chosing this direction:

• API providers should be able to accept only a subset of the API
  • tempting to include a mechanism to query API conformance in the API itself (and possible make it the only required part of a conforming implementation)
• how much should this be tied to Xi, if at all?
  • some things might be more efficient if provided by the core, then again the core should not become bloated
• what gets included and what does not?
  • this comes down to a lot of case-by-case decisions, so some clearly stated overall criteria and/or guiding philosophy would be helpful
• how does Xi (or rather the various Xi frontends) handle everything that is out of scope of the API?

[cmyr]

It might be worth looking at Microsoft's language server protocol (blog post) for inspiration, here?

I think one of my next steps will be trying to play around with the implementation of some UI-dependant plugin, to try and get a sense for how that interaction feels.

[cmyr]

It might be worth looking at Microsoft's language server protocol (blog post) for inspiration, here?

I think one of my next steps will be trying to play around with the implementation of some UI-dependant plugin, to try and get a sense for how that interaction feels.

[AljoschaMeyer]

There is a key difference to the LSP though. The LSP is about giving information with predefined semantics to the editor, which than handles it as it deems fit. The editor frontend protocol would basically do the opposite: Send abritrary data to the editor, which then presents it in a specific way. So the two protocols would nicely complement each other.

edit: Actually, I'm not so sure about this anymore. The LSP includes features like notifications or completions. Although one could argue that autocompletion should not be part of the frontend protocol, since it needs to be requested by the editor. And notifications don't really fit into the LSP, there is nothing language specific about them. They are just communication between a plugin and the editor, which is what the frontend protocol should be about.

[AljoschaMeyer]

There is a key difference to the LSP though. The LSP is about giving information with predefined semantics to the editor, which than handles it as it deems fit. The editor frontend protocol would basically do the opposite: Send abritrary data to the editor, which then presents it in a specific way. So the two protocols would nicely complement each other.

edit: Actually, I'm not so sure about this anymore. The LSP includes features like notifications or completions. Although one could argue that autocompletion should not be part of the frontend protocol, since it needs to be requested by the editor. And notifications don't really fit into the LSP, there is nothing language specific about them. They are just communication between a plugin and the editor, which is what the frontend protocol should be about.

[infogulch]

It's been a couple months since the last update here and it appears that the community is starting to coalesce around Language Server Protocol (LSP), including for Rust via RLS.

A good way forward might be to create a generic LSP xi plugin that shuffles messages between a LSP server and the xi server.

[infogulch]

It's been a couple months since the last update here and it appears that the community is starting to coalesce around Language Server Protocol (LSP), including for Rust via RLS.

A good way forward might be to create a generic LSP xi plugin that shuffles messages between a LSP server and the xi server.

[cmyr]

@infogulch: I actually started working on this a week or two ago, just testing out RLS with xi's existing (very basic) plugin support, which was able to request completions and print them to the console. I definitely think that LSP support is something we will be working on as soon as the plugin story coheres a bit more.

if you're interested:

[cmyr]

@infogulch: I actually started working on this a week or two ago, just testing out RLS with xi's existing (very basic) plugin support, which was able to request completions and print them to the console. I definitely think that LSP support is something we will be working on as soon as the plugin story coheres a bit more.

if you're interested:

[infogulch]

Awesome, that sounds exciting!

Just curious, how do you expect to implement this? Will xi speak LSP natively or will there be a plugin that translates between the two protocols?

[infogulch]

Awesome, that sounds exciting!

Just curious, how do you expect to implement this? Will xi speak LSP natively or will there be a plugin that translates between the two protocols?

[cmyr]

the xi-client will speak the xi client protocol, but my current thinking is that, where possible, the naming and layout of certain types (such as a completion group, etc) will be identical to the LSP implementation. (None of this is nailed down)

[cmyr]

the xi-client will speak the xi client protocol, but my current thinking is that, where possible, the naming and layout of certain types (such as a completion group, etc) will be identical to the LSP implementation. (None of this is nailed down)

[bbigras]

Any progress on LSP support?

[bbigras]

Any progress on LSP support?

[cmyr]

@bbigras no, hopefully later this year.

[cmyr]

@bbigras no, hopefully later this year.

[estk]

@cmyr I am interested in doing the work necessary for RLS/LSP integration. Would you have some time to write up a mentor doc for me on it?

[estk]

@cmyr I am interested in doing the work necessary for RLS/LSP integration. Would you have some time to write up a mentor doc for me on it?