Evaluate moving on top of lsp-mode

[memeplex]

Elpy builds on top python.el, it has a healthy tradition of not reimplementing what already has been effectively achieved elsewhere. Now, I can't yet say it's effective, and maybe it's too soon, but there clearly is a lot of overlap between lsp-mode and elpy and other ide-like modes. One could say: ok then, let's embrace diversity. But the truth is that: 1. Probably not everything elpy offers will eventually be part of lsp-mode (AFAICS testing, profiling, integration with interpreter won't) and 2. lsp-mode automatically takes advantage of python server improvements, because of the industry-wise modularization it promotes (it's a sad fact this had to wait until extensible editors became a fad instead of happening ten to twenty years before...). So it might be worthwhile assessing what lsp-mode is already offering and the possibility of a big refactor to simplify and further modularize elpy, don't you think?

[gopar]

This is just my opinion but I don't think there will be a refactor any time soon. My understanding is that lsp is still changing/breaking and won't be 'stable' for at least another while (I could be wrong 🤷‍♂️)

Also, looks like there is integration for things like interpreter, debugging, etc

[galaunay]

I gave it a try 4 month ago, because it was mentioned already (#1478). My branch dedicated to that doesn't work anymore, as the implementation changed.

So I agree with you that it would be nice to rely on lsp, but I agree with gopar that we don't want to do that too early...

Do we have any information on when lsp would be more stable ?

[memeplex]

@galaunay do I close this one or do you close #1478? I think the description of this issue is more precise but I don't really care which one is closed while one is.

[azzamsa]

So I agree with you that it would be nice to rely on lsp, but I agree with gopar that we don't want to do that too early...

I read closely their issues, seem like there are still plenty things to do. I don't believe we can use it for 'production' usage, imho.

[azzamsa]

emacs-lsp author is ready to assist if we're ready to move on the top of lsp-mode.

If we did this, emacs-lsp still delegates syntax highlighting to elpy (language-specific project). I would like to test tree-sitter, for syntax highlighting rather than to rely on python.el

[galaunay]

@azzamsa good to know. I made a branch for that a few months ago, and it seemed doable without too much hassle. It would also allow to massively reduce Elpy's codebase, which is nice.

But I think that before taking a decision we need a proper comparison between Elpy's features and what LSP offers.

If we did this, emacs-lsp still delegates syntax highlighting to elpy (language-specific project). I would like to test tree-sitter, for syntax highlighting rather than to rely on python.el

It looks nice indeed.

[azzamsa]

But I think that before taking a decision we need a proper comparison between Elpy's features and what LSP offers.

Yes, this was my first plan. I am still looking for a free time. :)

[pszynk]

Merging the functionality of emacs-lsp with elpy would be great.

@galaunay @azzamsa is this idea still alive?

[gopar]

I don't think this will ever happen. LSP proven to be very robust (I switched to it this year). Theres nothing to merge into elpy, if anything its either use elpy or lsp, there's no benefit in using both in my opinion.

[pszynk]

Thanks, that's a shame. LSP indeed works pretty good. I guess extracting some features from elpy codebase for yourself is possible.

[austinweisgrau]

Just my 2 cents, lsp can have a lot of issues with latency and a package like elpy can be preferable to lsp modes for that reason. I keep trying lsp but switching back to elpy due to latency issues and still not finding good workarounds / speedups.

now if elpy was built on top of python treesitter - that might be cool