feat: support (Neo)Vim by coc.nvim

[Freed-Wu]

https://www.npmjs.com/package/coc-nix

Refer:
https://github.com/valentjn/vscode-ltex/blob/3d0cb8cd9b4d0dc8ef6c08a4f376767820678cf6/src/extension.ts#L8-L14

Difference is vscode-ltex/coc-ltex uses a customized python script
https://github.com/valentjn/vscode-ltex/blob/3d0cb8cd9b4d0dc8ef6c08a4f376767820678cf6/tools/patchForTarget.py
to patch code
we use c language macro preprocessor cpp

[jnoortheen]

@Freed-Wu from my understanding, coc-nix should be able to use this extension as is. If there is any particular incompatibility, it can be handled by settings or through the extension code. Is there any reason choosing to patch the typescript code?

[Freed-Wu]

coc-nix should be able to use this extension as is.

https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensions#differences-between-coc-extensions-and-vs-code-extensions

[jnoortheen]

coc-nix should be able to use this extension as is.

https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensions#differences-between-coc-extensions-and-vs-code-extensions

I see, in these cases, I suggest using the nil/nixd directly as the LSP servers. I want to keep the codebase lean as much as possible.

[Freed-Wu]

using the nil/nixd directly as the LSP servers

I tend to provide better user experience by providing an extension, just like VS Code. For example, VS Code also can use nil/nixd directly as the LSP servers.

[jnoortheen]

I tend to provide better user experience by providing an extension, just like VS Code. For example, VS Code also can use nil/nixd directly as the LSP servers.

Since the package requirements for vscode and coc-nvim is different, I'd take the route of creating a separate package for coc-nvim. If you still intent to keep this under this repo, this can be a workspace package with different requirements and packaged/published separately.

[jnoortheen]

Another option, to keep this compatible with coc-nvim, is using https://docs.npmjs.com/cli/v10/configuring-npm/package-json#optionaldependencies to define coc package and use it in the code.

[Freed-Wu]

you still intent to keep this under this repo, this can be a workspace package with different requirements and packaged/published separately.

There are many same code between VS code client and (Neo)Vim client. a patch can reuse many code.
If you want a seperate packege, just run scripts/patch.sh.

[Freed-Wu]

is using https://docs.npmjs.com/cli/v10/configuring-npm/package-json#optionaldependencies to define coc package and use it in the code.

Looks intereasting. Hope it will not be too complicated. Can it still work for typescript?

[jnoortheen]

Sorry to nitpick, but I don't want to patch an already dynamic codebase/language.

[Freed-Wu]

Can optionalDependencies work for typescript? That means when vscode cannot be imported, import coc.nvim.

[jnoortheen]

Can optionalDependencies work for typescript? That means when vscode cannot be imported, import coc.nvim.

Yes it would support optional imports.

[Freed-Wu]

code cannot work: (comes from GPT), anything I did wrong?

type ExtensionContext = 
  | import('coc.nvim').ExtensionContext 
  | import('vscode').ExtensionContext;

let contextType: ExtensionContext | undefined;

try {
    contextType = require('coc.nvim').ExtensionContext;
} catch (e) {
    contextType = require('vscode').ExtensionContext;
}

export function activate(context: InstanceType<typeof contextType>) {
    console.log('Extension is activated!');
}

	"devDependencies": {
		"@types/node": "^12.12.0",
		"@types/vscode": "^1.52.0",
		"typescript": "^4.3.5"
	},
	"optionalDependencies": {
		"coc.nvim": "^0.0.80"
	}

❯ node_modules/.bin/tsc
src/extension.ts:2:12 - error TS2307: Cannot find module 'coc.nvim' or its corresponding type declarations.

2   | import('coc.nvim').ExtensionContext
             ~~~~~~~~~~


Found 1 error in src/extension.ts:2

expected:

When we add coc.nvim, we linter for vim client, otherwise, we linter for vscode client.

[jnoortheen]

@Freed-Wu you can start from here if you are comfortable with typescript . IMHO, other coc-* extensions I checked , seems to be kept as a separate pacakge in separate repo. It is easier that way.

[Freed-Wu]

Yes, a demo is:

import type { ExtensionContext } from 'vscode';
import type { ExtensionContext as ExtensionContext_ } from 'coc.nvim';
let vscode
try {
	vscode = require('vscode');
} catch (error) {
	vscode = require('coc.nvim');
}

export function activate(context: ExtensionContext | ExtensionContext_) {
	vscode.window.showInformationMessage("hello")
}

[jnoortheen]

Yes, a demo is:

import type { ExtensionContext } from 'vscode';
import type { ExtensionContext as ExtensionContext_ } from 'coc.nvim';
let vscode
try {
	vscode = require('vscode');
} catch (error) {
	vscode = require('coc.nvim');
}

export function activate(context: ExtensionContext | ExtensionContext_) {
	vscode.window.showInformationMessage("hello")
}

Looks tenable, I suggest having aliases like below where feaisble

import type { ExtensionContext as VExtensionContext } from 'vscode';
import type { ExtensionContext as  CExtensionContext } from 'coc.nvim';
type ExtensionContext = VExtensionContext | CExtensionContext;

[Freed-Wu]

I have done some experiments for some VS code extensions:

https://github.com/wader/vscode-jq/pull/8/files

And I found some problems:

type LanguageClient = LanguageClient_vscode | LanguageClient_coc;
export class Client extends LanguageClient {

tsserver 2422: A class can only implement an object type or intersection of object types with statically known members.

Is there any solution to solve it?

[jnoortheen]

@Freed-Wu I suggest having two workspace-package/module (if the functionality differs in coc & vscode clients) instead of extending the union type.