Oni: GUI Integration with ALE or similar alternatives

[akinsho]

@bryphe I think that there is/has been some conversation regarding how oni can/will/might integrate with vim plugins e.g #886 but specifically in this case, ALE a plugin which is the only asynchronous linter and autoformatter that I'm aware of for vim. I was thinking that there is a lot of very good work being done by viml plugins like ALE (neovim language server client) and rather than reproduce that work for oni i.e separate plugins for eslint, tslint, refmt(for reason) etc., ale currently supports around thirty different languages with linters and fixers where available and is only growing.

The plugin works in Oni populating the signcolumn and echoing error messages I was thinking that it might it be worth looking into feeding the output of plugins like this into the error highlighter (or maybe taking info about if a line is highlighted in vim and rendering that with oni's highlights. Also showing the output in its hover box with what would otherwise be outputted to the echo msg area.

I don't know if this will result in an implementation specific to ale or whether it'd be possible to generalise the implementation so that other plugins like neomake or syntastic errors etc could be output using oni's gui features.

I wonder what your thought on that are? fyi i'd be happy to have a look at whether or not it's even possible (I currently can't really tell from a cursory glance at ale's repo)

[bryphe]

My hope for the project is that I can diminish the need for VimL-based plugins. Oni actually supports the LSP, but it's a bit behind more mature implementations like ALE (currently).

I'm not opposed to supporting / integrating with VimL plugins, but it is challenging because there is a huge variety and if someone wants to run VimL plugins, it can become difficult to manage things like conflicting settings or conflicting out-of-box plugins. The less we have in the VimL layer, the less potential for Oni to conflict with a power user's Vim settings (and the simpler our configuration story can be). With #973 , I'm working towards having less of a VimL surface area than we have today.

However, if this is something that people would like - deeper integration with VimL plugins - I believe it should be doable as a plugin, even if it isn't implemented in the core project. For example, I could imagine an Oni plugin that bundles both ale.vim and some JS code to hook up error highlighting / messages. Oni's extensibility layer should be flexible enough to support this (if not, it should be fixed 😄 ) - there just might need to be some glue code to bring Oni + ALE together. Would be a good exercise to see how that might work!

[akinsho]

@bryphe I completely understand and tbh I don't imagine there is some standard way that vim plugins interact with things like the signcolumn or echo area that are likely to be generalisable and implementing the code in Oni itself rather than as a plugin would likely lead to more harm than good. If the general plan is to move towards oni plugins with neovim as the "engine" then that's fair enough.

I might have a very brief stab at seeing if this can be easily implemented as a plugin, and if you don't mind leave this thread open for a (very short period of time) whilst I attempt it so I can perhaps pick your brain if I run into any issues. I'll use the tslint plugin as a template for this and see how it works out.

[bryphe]

If the general plan is to move towards oni plugins with neovim as the "engine" then that's fair enough.

Yes, my hope is that the plugins will be 'orthogonal' and 'modular' - the extensibility layer I have in mind actually has more in common with Emacs than any other editor. Architecturally, I'd like Oni to be a modular pack of 'lego blocks' (each item in Services is basically one of these blocks) as opposed to a monolith - easy to rearrange or bring your own lego blocks via plugins to get your editor to behave exactly as you want.

I might have a very brief stab at seeing if this can be easily implemented as a plugin, and if you don't mind leave this thread open for a (very short period of time) whilst I attempt it so I can perhaps pick your brain if I run into any issues. I'll use the tslint plugin as a template for this and see how it works out.

Sounds great! The most interesting plugin we have today is #922 that @TalAmuyal is working on - might be worth taking a pass through that.

We also have an API for sending diagnostics from a plugin directly:
https://github.com/onivim/oni-api/blob/45257828b9652356179c58a92cd309511543390b/src/index.ts#L219
(Which might be useful for hooking up here, specifically for this case). The interesting piece is how we hook up VimL state to Oni - we do that today here: https://github.com/onivim/oni/blob/d94397e5ad058410133c55a98e34ce90eae7d077/vim/core/oni-core-interop/plugin/init.vim#L13 but this is a piece that isn't modularized or generalized today.

[akinsho]

@bryphe going to close this now as integrating ale will require forking the library an making may heavy changes. Hopefully was more vim ui is externalised Oni can render output from plugins like ale in a nicer format

[bryphe]

Makes sense! If we decided this was something that plugin authors wanted, we could potentially build some helpers to facilitate VimL <-> Oni interop. But it would still be up to the plugin authors to opt-in to supporting that extra functionality.