☂️ Editor Support

[NicholasLYang]

Description

Rome should work with more editors than VSCode. Because we use the language server protocol (LSP), it should be relatively easy to get Rome working with any editor that has an LSP client. All that's left is to document the process and make it easy to find the server binary. For editors that have poor LSP support like IntelliJ, we don't have the expertise to write a plugin, but perhaps someone sufficiently motivated could tackle it?

We should also document the fact that we use an LSP so that people know they can use an LSP client.

• Emacs
• Vim
• Sublime
• Atom
• IntelliJ

Poll

Related poll #3544

Building an new integration

Adding support for a new editor should be straightforward for all editors supporting the LSP. Rome ships with a lsp-proxy command to which any editor can connect to.

JetBrain IDEs

Visit the relevant issue to upvote the ticket.

[mattmarcello]

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

[ematipico]

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

Thank you! Unfortunately the team doesn't have enough knowledge to help you out. Meaning we don't know how to make plugins for the listed editors.

One thing though, is that we'd favour plugins that use the LSP protocol.

I found this example on GitHub, maybe it can help: https://github.com/MunifTanjim/eslint.nvim

[MichaReiser]

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

Hey @mattmarcello We aren't familiar with how to write and bundle vim plugins.

The most straightforward implementation would be if vim (natively or through a plugin) supports the LSP protocol which we already use for our VS Code plugin.

@leops which binary and what's the command to start Rome in the LSP mode?

Feel free to ping us on this issue or join our discord channel.

Edit: Some links that I gathered a while back. One option is to fork prettier's or another formatter's plugin. This has the downside that other commands like linting wouldn't be supported out of the box. Or we use an lsp plugin instead:

Other formatter plugins

• Prettier vim,
• neoformat,
• ale,
• coc-prettier,

LSP Plugins

• vim-lsp
• neovim)

[IWANABETHATGUY]

I could help for writing documentation about neovim plugin

[mattmarcello]

I'm on vacation for a few days but I'll try to dig into this if I have sometime next week. Thanks for the resources.

[leops]

@leops which binary and what's the command to start Rome in the LSP mode?

Currently the binary that needs to be spawned is rome_bin with the argument __print_socket, but once #3143 is merged the binary will be rome_cli (I'm going to remove the daemon prefix from the PR so the command will still be __print_socket for now). This command will make the CLI print the "address" of an OS-specific socket (domain socket on Unix, named pipe on Windows) the Language Client can connect to.

[IWANABETHATGUY]

I am not a guru of nvim, here is a nvim config that has the same functionality as vscode extension in the latest rome (v0.9.2-next)
(lint, formatter) #2131 (reply in thread)

[alecandido]

In principle, coc.nvim is a lsp client plugin for (neo)vim running on NodeJS, such that it should make plugins as similar as possible to VSCode once, citing them:

Make your Vim/Neovim as smart as VSCode.

I guess useful resources should be:

• Differences between coc extensions and VSCode extensions
• coc-css seems to me to be one of the simplest plugin, relying on the corresponding VSCode extension (it is literally a dependency)
• Register custom language servers if you can provide the language server as a CLI or different Node package (most likely the VSCode extension might be a suitable option), you can test and give information to users on how to configure the server (even if not packaged as a nice extension)

[antonk52]

If you want to have support in vim/neovim I strongly recommend not to lean in towards a single LSP client plugin like coc.nvim. Instead if you have a standalone LSP executable it can be used by both vim/neovim and other terminal based text editors(emacs)as well as it could also be plugged into coc.nvim.

Picking coc.nvim significantly lowers a percentage of vim/neovim users who would be willing to switch to or include coc.nvim for Rome alone.

An example how a single LSP client can be enabled for both neovim with lspconfig and coc.nvim

[strager]

@antonk52 I think @alecandido was not suggesting that Rome only support coc.nvim. Rather, coc.nvim is one ecosystem which Rome could plug into and support.

coc.nvim might be the easiest for Rome to integrate with (in terms of engineering time) because Rome already has a working and maintained Visual Studio Code extension.

[alecandido]

@strager thanks, that's what I thought. I believe @antonk52 was just suggesting to broaden the audience: since coc.nvim is just another LSP client, you can support more vim/neovim's clients, more or less with the same approach, and it makes sense.

However, even if I was asking to support coc.nvim as a generic "support a LSP client for vim/neovim", now I'd stress slightly more the coc.nvim proposal. While for VSCode there is a single client, for vim/neovim there is not a unique one (coc.nvim, nvim-lspconfig, vim-lsp, ale, LanguageClient-neovim).
So, you can provide plugins for all of them. Or you can give instructions to set them up, given a unique server wrapper (I believe for Rome would be a bit more difficult then cssmodules, but I might be wrong). But I would suggest to start with one, and coc.nvim is a good candidate, just because in my experience is the most popular, but whoever will start of course will pick his favorite ^^

Of course, after the first it should be possible to keep going with the others. But, in a sense, I expect the second to be as complicate as the first one, since the server already exists.