feature: integrate vim.diagnostics with vscode.Diagnostics

[theol0403]

:h diagnostic-api has a bunch of methods to interact with buffer diagnostics. VScode also provides a Diagnostics API.

The main value for this is to hook vim.diagnostic.goto_next(severity) and vim.diagnostic.goto_prev(severity), which many people bind to ]e and [e, ]d, [d, etc.

However, full integration may be useful for plugins that interact with diagnostics or complex bindings.

Should be relatively doable.

[xiyaowong]

I did think about it, too. However, I am worried that it will bring more confusion to users than benefits.

[ollien]

I might give this a crack. I often find myself trying to use the minimap to find diagnostics, so I would actually use this

[theol0403]

Don't we want to support as many bindings out of the box as possible? Maybe we do not need the full integration, but hooking the navigation commands will be beneficial.

[xiyaowong]

How about creating a temporary nvim plugin for developing this feature? It would facilitate testing and contributions. Besides vim.diagnostics, there might be other functionalities as well. Once it’s refined, we can consider integrating it into vscode-neovim.

[theol0403]

Sounds good to me. There's some functionality from multi-cursor that I want to move to core as well, we should maybe create a "staging" extension to test experimental integrations.

[ollien]

How does an extension look, to you, if we have to integrate with VSCode functionality that isn't otherwise supported by vscode-neovim? I haven't investigated the multi-cursor extension too much, so maybe there's an "obvious" answer. Is it just "use a lot of eval"? haha

[theol0403]

I might give this a crack. I often find myself trying to use the minimap to find diagnostics, so I would actually use this

Perhaps we can use this as a proof of concept of one of the first features that would traditionally require support code on the extension side but we implement purely through Lua.

[theol0403]

Yeah traditionally we'd create a custom request and provide support on the vscode side. But we can try using only eval.

[ollien]

I'd prefer to avoid eval, as I think the semantics of that might be a bit weird (especially if we're using typescript, we'd have to compile down something minified to shove through, or put it all in lua strings. Neither is super elegant).

I need to look more closely at the request mechanism between the lua and TS side, but maybe we can have extensions do a single eval to "register" what requests they want somehow.

[theol0403]

Perhaps. Features like this are good examples of features that work in isolation, so would be nice to bundle as extension.

We could potentially bundle a ts file next to the Lua file, full of hooks, that we send over.

Otherwise, adding core support is fine.

Probably don't need access to the buffer manager to get the buffer URI, can use vscode.focusedEditor (something similar)

[xiyaowong]

Wait, do we really need full support for all these functions? That could be quite a lot of work. Maybe we could create a VS Code extension to handle this

[ollien]

Otherwise, adding core support is fine.

Maybe there's some history I'm not understanding here, so please do let me know if I'm off base, but if we're modifying core anyway, what's the benefit of having a separate nvim plugin?

[theol0403]

If we're modifying core, then yes, there can't be an external plugin.

[xiyaowong]

what's the benefit of having a separate nvim plugin?

My original purpose was to facilitate development and contribution.

[xiyaowong]

We can export MainController for other vscode extensins, return "plugin" in the activate function

Currently there is a command "_getNvimClient" to get the nvim client. https://github.com/xiyaowong/vscode-tab-picker will use it.

[justinmk]

The main value for this is to hook vim.diagnostic.goto_next(severity) and vim.diagnostic.goto_prev(severity), which many people bind to ]e and [e, ]d, [d, etc.

This is a pretty weak justification, since those can be remapped to vscode variants.

Is there other motivation for this?

[theol0403]

Yes, the main purpose of this request is to map vscode variants. However, the main obstacle is there are no vscode commands to navigate by severity, so we would need to add some custom plumbing to provide the same API.

[justinmk]

Yes, the main purpose of this request is to map vscode variants. However, the main obstacle is there are no vscode commands to navigate by severity,

Is that worth the extra code?