• [^] # Re: Points de vue alternatifs

    Posté par . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 5.

    Dommage de ne jamais (l'article lié n'est pas plus disert) donner un seul exemple de ces "fonctionnalités les plus avancées" que LSP ne permettrait pas, surtout si on perd "énormément"..?

    Jetbrains, par exemple, a toujours boudé LSP pour ses produits (même s'il existe des plugins)

    Je cite cet article de 2018 autour de Rider (IDE .NET propriétaire) :

    Re-using the Language Server Protocol (LSP), an idea we discarded. LSP is great and does many things, but it's also a lowest common denominator. Some refactorings in ReSharper are impossible to implement in LSP without bolting on many customizations. It's also unclear how LSP should handle languages like Razor, which typically mix C#/VB.NET and HTML, CSS, and JavaScript. There would have to be an LSP component for the separate languages, but also one for the combined languages. LSP would introduce many complexities and provide little benefit for our particular use case.

    J'ai aussi trouvé cette discussion autour du support du LSP pour Kotlin dans Intellij (mais les remarques pertinentes s'arrêtent en 2018)

    Comme la situation des IDE Jetbrains n'a pas changée, je suppose que les équipes de Jetbrains estiment que ces "problèmes" subsistent, indépendamment des évolutions favorables des Language/Debug Server Protocols.

    Tu trouveras peut-être aussi cet article de fin 2020 intéressant. Quoiqu'on pense du LSP, je rejoins complètement une de ses remarques :

    LSP did achieve a significant breakthrough — it made people care about implementing IDE backends