Migrating to REditorSupport

[randy3k]

It’s pity that you are no longer supporting it. Are you interested in moving it to REditorSuport?

I will see what can be done with the lsp and this package.

[Ikuyadeu]

Sorry, about stopping support.
I am considering just send commit authority to you.
Because the current issues and pull requests are not solved.

[randy3k]

If you don’t want to migrate it to REditorSupport, we could also create a fork at REditorSupport and point users to there.

[randy3k]

I am writing to see your decision on migrating the repo to REditorSupport. You are already an owner of REditorSupport, so you should be able to transfer it if you want to. On top of that, you may also need to contact Microsoft to change the publisher to REditorSupport.

[randy3k]

@Ikuyadeu

I just want to reinitiate the discussion on migrating the repo to REditorSupport.
A similar issue was created for the debugger related packages developed by @ManuelHentschel
ManuelHentschel/vscDebugger#33

By moving the repo to a centralized place, I am sure users will be benefited and get less confused.

[randy3k]

By the way, it is impressive to see that @renkun-ken has contributions all around the places.

[qinwf]

Unified VS Code R plugin will provide a much better experience.

You do not need to teach the new users to install A and then B and the C.

Just get one Plugin and then it will automatically download the languageserver R package for you to get all the functionality going. That's it. It is simple.

I simplified some descriptions about how to set up R with VS Code before.

For example:

old introduction:

• VSCode + vscode-R + vscode-r-lsp + languageserver - VSCode R Langauage Support

now

• VSCode - vscode-R + vscode-r-lsp VSCode R Langauage Support

future

• VSCode - VSCode R Langauage Support

People are lazy. If there is an easy way to get things done, it will be much easier for them to adopt new technology.

[renkun-ken]

As VSCode-R-Debugger and httpgd are working better, my recommended tools of VSCode R support will become the following:

VSCode + vscode-R + vscode-r-lsp + languageserver + radian + VSCode-R-Debugger + vscDebugger + httpgd.

I can already feel the confusion from the future users.

However, combining them into much fewer projects may not look necessary to me. I think if the VSCode extensions could install their external R package dependencies automatically, e.g. vscode-r-lsp installs languageserver automatically, VSCode-R-Debugger installs vscDebugger automatically. Then a VSCode R Extension Pack could make it much simpler.

[qinwf]

If there are many plugins, it will be harder for users to do bug reports.

Some users in the past talked about they do not know if a issue is a vscode-R issue or languageserver issue and do not know where to report the bug for VS Code support for R.

[renkun-ken]

@qinwf, Yes, that's the main issue here.

[renkun-ken]

Sometimes, however, we are not sure where to put a certain issue. For example, it might first appear to be a bug in radian, but turns out to be a bug in vscode-R sending code to radian. But there's no point to combine radian and vscode-R.

But if it is only for bug reporting confusion, I think we could make a central place for all bug reporting if user is not sure where to put it.

[randy3k]

By the way, I fully support merging vscode-R and vscode-r-lsp. Originally I approached @Ikuyadeu to see they wants to add support of languageserver but for some reasons, they created a new project rather than adding the feature to vscode-R.

[renkun-ken]

If possible, I support merging all vscode-R, vscode-r-lsp, and VSCode-R-Debugger together.