Time to move efforts from omnisharp-emacs to lsp-mode? [Discussion]

[josteink]

First of all: This issue is not meant to offend anyone or anyone's current or previous efforts w.r.t. C# support in Emacs, nor the state of Omnisharp-Emacs.

As the mostly dormant csharp-mode maintainer, I am absolutely the last person on earth with a right to complain.

That said: for the best of the Emacs-ecosystem I think it's useful to at least start having this conversation.

I remember back in the days: Omnisharp-Emacs was a godsend when it was the only game in town. That was then. But a while ago Microsoft launched LSP as both a language-independent, editor-independent proposal, and it has grown some pretty good momentum and ecosystem.

For the uninitiated: LSP reduces the language-editor combinatorial explosion (N*M extensions/plugins) with a much more manageable N LSP-backends plus M LSP-clients situation.

Emacs has a bunch of language specific plugins: Omnisharp-Emacs, tide, emacs-racer and surely more.

All those plugins does pretty much the same: Emacs-APIs and bindings for autocomplete, auto-imports, refactoring, etc, by talking to some language backend of sorts. The code-duplication and amount of hours wasted writing that duplicate code must be immense.

And the user-experience is entirely inconsistent. It's not good. Compared to VSCode's OOB-experience, it's honestly pretty terrible.

With LSP we only need to implement one client, and that can talk to multiple different language backends. And that one client will behave 100% consistently across languages. With VSCode Microsoft really showed the world how well it can work when done right. And thus an LSP-based ecosystem flourished.

So far Emacs' LSP-support has not really been that great, and definitely not an option for C# developers.

But with one small patch from me lsp-mode gained C#-support recently. And a few updates later, Omnisharp-Roslyn's LSP-support is starting to work surprisingly well.

Despite seeing things lacking here and there, the overall experience is pretty good and reliable, and I'm going to try to use this as my default C# environment now.

And that's where I think you guys might want to join in: If you could put all that effort you would normally put into Omnisharp-Emacs into improving LSP-mode where it lacks coverage instead, we can all help make Emacs massively better to work with, not just for C#, but for all languages with a LSP-backend. That's like a 100x payoff for the same amount of code.

You have the background, you have the knowhow. And as joint-effort across the entire Emacs-verse the end-result is probably going to be better than you can manage on your own.

So how about it? How about we help lsp-mode also gain the best bits developed here, and help LSP also gain some momentum in the Emacs-verse?

[razzmatazz]

Hi @josteink.

Thanks for writing such a nice summary. Just yesterday I noted that there was your commit to support omnisharp-roslyn in lsp mode and I tried setting up it myself on my personal mac. And it actually works for me too. Aside for some performance issues, it looks to have way more features than omnisharp-emacs ever will.

And I do agree with your suggestion, that going LSP-way is way more scalable for everyone involved, including me, as lately I didn't get many features added to omnisharp-emacs, apart from bugfixes.

I will attach a link to this discussion/issue in README.md later so everyone can see this and then we can slowly depreciate omnisharp-emacs, i.e. it can then go into maintenance mode.

One thing we might be missing from emacs-lsp for C# at this moment is omnisharp-roslyn server installation code, which (I think) can be easily ported over to emacs-lsp/lsp-mode so new users can have a more seamless initial setup experience.

[hhyyrylainen]

Do you have installation instructions to share for such a setup? I'm unable to get lsp-mode to really do anything other than installing the roslyn server.

[razzmatazz]

Do you have installation instructions to share for such a setup? I'm unable to get lsp-mode to really do anything other than installing the roslyn server.

It didn't work properly for me either. But there may be good news in store (didn't try myself yet), though:

• https://github.com/emacs-lsp/lsp-mode/issues/1125#issuecomment-598032182

[josteink]

@hhyyrylainen : I just tried using latest version of lsp-mode and OOB it kinda worked.

• loaded a .NET core project (on Linux, if it matters).
• activated lsp, using M-x lsp.
• asked to install language server. completed successfully. latest version (as linked by @razzmatazz ?).
• code docs, code-navigation, etc works.
• auto-completion didn't seem entirely contextual, but it did provide feedback.

[razzmatazz]

@hhyyrylainen : I just tried using latest version of lsp-mode and OOB it kinda worked.

* loaded a .NET core project (on Linux, if it matters).

* activated lsp, using `M-x lsp`.

* asked to install language server. completed successfully. latest version (as linked by @razzmatazz ?).

* code docs, code-navigation, etc works.

* auto-completion didn't seem entirely contextual, but it did provide feedback.

lsp-mode now always retrieves the latest version of omnisharp-emacs from github, also there is update M-x call available, lsp-csharp-update-server IIRC, that updates your server binary to the latest version, too

[snippins]

lsp-mode seems to have some problems with mono projects, I can't get auto-complete to work while omnisharp-emacs still works fine. For dotnet core projects both works.

[ijacquez]

lsp-mode seems to have some problems with mono projects, I can't get auto-complete to work while omnisharp-emacs still works fine. For dotnet core projects both works.

Could you go into more details?

[AlonTzarafi]

I tried lsp-mode on emacs 26 one time but the performance was horrendous. However when compiling "gccemacs" branch (native compilation) of emacs 28 the performance issues disappeared. They both work fantastic but I stayed with omnisharp-mode because:

1. It has refactoring code actions which aren't implemented in C# of lsp-mode
2. The server seems to crash less in omnisharp-mode
3. It's still a tiny bit faster

So I just want to say that lsp-mode's main disadvantage - performance - is in the process of fading away, and that it's going to be competitive with highly optimized packages like omnisharp-mode.

[razzmatazz]

Hi @AlonTzarafi

I should note, that code actions are already implemented in lsp-mode (I know, since I have added a PR to omnisharp-roslyn myself :) -- https://github.com/OmniSharp/omnisharp-roslyn/pull/1795

Also, omnisharp-emacs has not received a lot of code/attention for a while and I suspect lsp-mode already has more features compared to omnisharp-emacs, except for maybe unit-test runner (which I am attempting to work on to port over to lsp-mode)

[AlonTzarafi]

@razzmatazz Thanks for the heads up. I was using an old omnisharp server 😅

[josteink]

On my part, I'm now using eglot and consider this issue moot. Closing this issue.

Thanks for the service throughout the years! It helped get my C# flows into Emacs, for sure!