N. D. M. : dépêche réécrite en octobre 2022 suite à la demande de purge du compte de l'auteur initial
LSP (Language Server Protocol) est un protocole ouvert basé sur JSON-RPC pour la communication entre le logiciel éditeur / IDE et un serveur qui lui fournit les informations sur un langage spécifique.
Aller plus loin
- Documentation (GitHub Microsoft) (143 clics)
- LSP / Emacs (113 clics)
- LSP / Vim (205 clics)
- Langserver.org: a community-driven source of knowledge for Language Server Protocol implementations (85 clics)
# Utile aussi aux développeurs de langages
Posté par barmic 🦦 . Évalué à 8.
Ça aide aussi pas mal les développeurs de langages qui peuvent implémenter un LSP pour être intégré dans toute une série d'éditeurs sans avoir à l'implémenter dans chacun (directement ou via une extension).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utile aussi aux développeurs de langages
Posté par swilmet . Évalué à 4.
Ça aide pas mal, mais ce n'est pas le seul choix possible (pour les concepteurs d'un langage ou d'une plateforme de développement). LSP est un bon premier choix, mais il y a souvent moyen de faire mieux en développant des outils spécialisés (en se basant quand même sur des bibliothèques plus générales qui font déjà une grosse partie du boulot).
Il y a l'exemple d'Arduino qui a développé son propre éditeur de texte. Ça a l'avantage que les fonctionnalités sont mieux intégrées, avec une application qui Juste Marche (si tout va bien). Mais ça demande plus d'efforts de développement, par exemple il y a quelques années il n'y avait pas d'onglets pour ouvrir plusieurs fichiers dans la même fenêtre, plutôt embêtant…
Pour catégoriser un peu, je dirais que :
- Il y a les éditeurs généralistes, qui essayent de convenir à un maximum de langages (et souvent avec un système d'extensions/plugins). Plus fastidieux pour tout installer et configurer.
- Il y a les éditeurs spécialisés, qui intègrent mieux les fonctionnalités pour un langage particulier.
C'est là que LSP ne convient pas toujours pour les éditeurs spécialisés.
Pour faire une analogie : la question entre utiliser une clé à molette ou plusieurs clés de tailles spécifiques.
PS : j'ai été de ceux qui ont développé des bibliothèques pour faciliter le développement d'outils de programmation (édition de texte, navigateur d'API). Donc mon avis est peut-être baisé (biaisé pardon).
[^] # Re: Utile aussi aux développeurs de langages
Posté par barmic 🦦 . Évalué à 6.
Comme tu le dis c'est un très bon moyen de créer un éditeur anémique. Ardiuno avait pour lui d'avoir l'attrait du matériel, mais ce n'est pas le cas de tous les langages. Il faut donner une bonne raison à des développeurs qui ont déjà passé du temps sur leur éditeur à passer au tiens pour apprendre ton langage et ton éditeur.
Proposer simplement une intégration dans un grand nombre d'éditeur sur chaque plate-forme, c'est un confort indéniable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utile aussi aux développeurs de langages
Posté par swilmet . Évalué à 7.
Arduino est un exemple où c'est la même entreprise qui a développé le matériel, la plateforme de développement et l'éditeur de texte. Le tout pour que ça convienne à des débutants (pour commencer et écrire son hello-world avec une led qui clignote, ça fait le job). Mais c'est clair que ce ne sont pas des spécialistes (à la base) pour créer un éditeur de texte.
Autre exemple, la société JetBrains qui a développé IntelliJ Idea (pour Java), CLion (pour le C/C++), etc. Ce sont des IDEs spécialisés. Mais ce n'est pas JetBrains qui a créé Java évidemment. JetBrains s'est spécialisé dans le développement d'outils pour les développeurs, et ça a plutôt bien fonctionné. Ils ont créé une software product line, partageant du code entre leurs différents IDEs et outils.
Donc, je dirais, l'approche LSP est une bonne approche dans un premier temps (pour les concepteurs d'un langage), et si le langage devient suffisamment populaire, d'autres personnes/entreprises s'occupent de créer d'autres outils autours, des plugins additionnels pour certains éditeurs de texte, ou un éditeur de texte spécialisé, etc.
Il en faut donc pour tous les goûts : pour les débutants qui veulent un petit éditeur de texte spécialisé qui fait bien son boulot, out-of-the-box ; des éditeurs multi-usages et hyper-configurables ; etc.
Et si le LSP pour un certain langage est implémenté avec du code réutilisable (en-dehors du protocole LSP), c'est d'autant mieux pour ceux qui ont envie de créer un éditeur spécialisé. Je pense notamment à la libclang (du projet LLVM), qui est une brique de base pour l'implémentation d'outils autours du C et C++ (auto-complétion, refactoring, et bien d'autres). La libclang permet notamment l'implémentation du protocole LSP, mais ça peut être aussi utilisé directement en-dehors de LSP. Bref, la flexibilité à son maximum ;-)
[^] # Re: Utile aussi aux développeurs de langages
Posté par barmic 🦦 . Évalué à 4.
Jetbrain ont démarré bien avant la création de LSP et n'ont aucun intérêt à y passer, ça remettrait en cause l'un de leur principal argument de vente.
Au contraire la plupart des IDE qui n'ont pas d'intérêt commerciaux ou qui ne sont pas les leaders l'accueil avec intérêt.
C'est architecturalement, de loin, une bien meilleure solution. Tu as une bien meilleure séparation des sujets et un découpage qui peut te permettre de de garder un éditeur fluide. Peut être qu'LSP doit évolution pour être fonctionnement plus complet, mais ça n'est pas ce qu'il y a de plus complexe.
Donc oui l'inertie, le jeu des concurrences et le manque de maturité font que ça n'est pas la solution que l'on trouve partout aujourd'hui, mais si tu regardes l'usage actuel par rapport à la jeunesse du truc c'est assez fulgurant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utile aussi aux développeurs de langages
Posté par PLuG . Évalué à 2.
D'un autre coté, avec l'IDE Arduino c'est compliqué de gérer un projet avec plusieurs fichiers, d'avoir de la coloration syntaxique ou même de simples alertes sur des erreurs de syntaxe.
Rapidement il faut utiliser PlatformIO avec un "IDE" comme VScode ou bien Atom pour retrouver un environnement de développement plus sérieux.
Perso je trouve l'initiative PlatformIO intéressante et plutôt bien foutue pour intégrer les boards matérielles et compiler du code adapté aux microcontrôleurs. C'est l'exemple inverse de Arduino : au lieu de tout refaire de zéro, prendre le meilleur d'un éditeur, le meilleur de l'intégration des microcontrôleurs de Arduino, et pourquoi pas LSP pour la partie IDE.
[^] # Re: Utile aussi aux développeurs de langages
Posté par claudex . Évalué à 4.
Pour les éditeurs spécialisés pour le langage pour lequel ils sont développés. Mais, ça peut être bien pratique d'avoir un support d'autres langages, parce qu'on n'a rarement qu'un seul langage dans un projet. Si on fait du C++, on se retrouve avec make/cmake/… au moins, mais ça peut être pratique d'avoir un support limité de Python ou Rust pour s'intégrer avec un autre projet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Utile aussi aux développeurs de langages
Posté par swilmet . Évalué à 3.
Yep, je suis d'accord que d'avoir une application lancée pour le C++, et une autre pour CMake, c'est pas terrible à l'usage.
Imaginons que pour CMake la GUI aurait un intérêt d'être différente (plus simple, sans doute), que pour éditer du C++. C'est bien je trouve d'avoir des GUI spécifiques pour un usage particulier (menu et barre d'outils avec contenu différent selon le contexte).
Le truc c'est que, habituellement, les onglets pour ouvrir plusieurs fichiers dans une même fenêtre se trouvent en-dessous du menu et de la barre d'outils. Et si ces derniers veulent changer selon le contexte, ça peut faire bizarre. Pareil pour ce qui se trouve dans le panneau latéral.
Donc voici mon idée du jour : avoir les onglets au-dessus du menu et de la barre d'outils (et du panneau latéral), pour que tous ces éléments puissent changer selon le contexte. Et certains onglets pourraient d'ailleurs afficher un terminal au lieu d'un éditeur de texte.
Et ces onglets qui se trouvent au-dessus, ça pourrait même s'appeler une barre des tâches. Oh tiens… :-)
[^] # Re: Utile aussi aux développeurs de langages
Posté par barmic 🦦 . Évalué à 3.
C'est pourtant le fonctionnement de toutes les outlines. Ça doit pas être si choquant.
Remarque que ce n'est pas parcage tu as plusieurs fenêtres que tu as plusieurs programmes ;)
Ce qui est intéressant c'est de voir les interactions que tu veux avoir. Tu veux probablement manipuler le build depuis tes sources sans avoir à changer de fenêtre (tu garde un feedback court pour le cycle code/test unitaire) et c'est quand tu modifie le cmake que tu as besoin de l'autre fenêtre. Mais attention il faut que l'éditeur soit mis au courant (soit il dit scruter le fichier et le recharger soit être informé manuellement ou via une ipc). Ça se gère, mais ça devient un peu plus embêtant quand tu veux proposer une modification du fichier depuis les sources. Tu commence par utiliser une bibliothèque mais tu ne l'a pas encore déclarée comme dépendance, certains IDE te proposent de l'ajouter eux-même.
Tu te retrouve avec 2 outils qui modifie le même fichier, il va te falloir de la synchronisation et donc un certain couplage entre les deux. Tu as aussi des outils qui parsent le fichier et tu espère qu'ils vont comprendre la même chose.
Tout ça pour dire que si ça n'est pas une mauvaise idée, c'est compréhensible de faire des IDE tout en un car c'est bien plus simple à créer et laisse bien plus de souplesse quant aux fonctionnalités que tu peux vouloir fournir.
Pour ce qui est d'utiliser des UI différentes d'un fichier à l'autre NetBeans le fais beaucoup il me semble, mais quand j'étais passé de NetBeans à intellij j'ai trouvé que garder un format texte, mais proposer un très haut niveau d'aide à l'édition était plus pertinent.
Et au passage, perso j'ai viré tous les onglets. Je navigue entre les fichiers via l'arborescence, via l'historique et via une recherche sémantique (je vais à la classe MachinTruc), je trouve les onglets contre productifs car ils m'oblige à les organiser (les supprimer, modifier leur ordre,…)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Question bête…
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
… suite à l'impression de ne pas avoir bien compris.
Il s'agirait donc d'un protocole visant à permettre de communiquer en direct des informations sur la coloration syntaxique (et plus) à destination des IDE ? Est-ce bien ça ? Y a-t-il bien un lien obligatoire entre serveur et format de données ? Si oui, La question de l'utilité de lier ce format à un serveur (souvent) centralisé plutôt que de spécifier un format de données, indépendamment de la manière dont elle serait obtenues ne se pose-t-elle pas ? Le but pourrait-il être au passage de prétendre justifier un peu plus de télémétrie et de récolte d'informations confidentielles ?
Désolé, étant nul en orthographe et un peu sourd, chez moi, mirosoft comme Redmond rime avec suspicion et corruption.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Question (encore plus) bête…
Posté par redo_fr . Évalué à -1.
… N'étant pas développeur.
A-t-on la certitude que le code reste bien sur la station locale et n'est pas envoyé pour
copie"analyse" au serveur ? Outre le problème de la bande passante, le lien quasi-permanent avec le serveur, etc. pose le problème de la confidentialité/sécurité du code en cours d'édition.Est-il possible d'héberger soi-même le serveur (je pense surtout aux entreprises)?
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Question (encore plus) bête…
Posté par Matthieu Duchemin (site web personnel) . Évalué à 10.
Le serveur est hébergé sur ton PC. Le client est implémenté dans l'IDE et permet de dialoguer avec le serveur. Chaque language de programmation va avoir son propre serveur qui est un simple programme qui tourne sur ton PC. Par exemple si tu fait du dev en PHP, ruby et python, tu auras 3 serveurs LSP qui vont être instanciés sur ta machine.
Par exemple il existe un package LSP pour emacs https://emacs-lsp.github.io/lsp-mode/
Avec LSP-mode le serveur est instancié dès que l'on ouvre le code source d'un language spécifique. Tant que je n'ai pas ouvert un code source PHP le serveur pour PHP ne tourne pas. Mais dès que j'en ouvre un, le serveur est instancié par lsp-mode. Cela ajoute un délai à l'ouverture du fichier de quelques secondes pour que le serveur soit instancié, mais après c'est rapide.
[^] # Re: Question (encore plus) bête…
Posté par jigso . Évalué à 3.
Sous Emacs il existe depuis longtemps qqe chose de similaire pour éditer du Java conjointement avec Eclipse : un plugin dans Eclipse fait office de serveur. Il suffit de lancer Eclipse et charger son projet, et ensuite de connecter Emacs : l'édition se fait évidemment dans Emacs mais avec toutes les fonctionalités de coloration, autocompletion, recherche etc d'Eclipse : pas besoin de redevelopper le parsing et l'analyse des sources dans Emacs.
Le serveur a évidemment accès à tout le source pour remplir son role, mais tout reste bien en local.
[^] # Re: Question bête…
Posté par barmic 🦦 . Évalué à 10. Dernière modification le 19 mai 2021 à 09:03.
Il n'est pas question d'un serveur publique centralisé accédé via internet, mais de serveur qui sont lancés en tâche de fond sur ton ordinateur (comme le serveur X par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Question bête…
Posté par Pinaraf . Évalué à 6. Dernière modification le 19 mai 2021 à 09:26.
Nop, pas forcément la coloration syntaxique, plutôt le «et plus» : complétion de code, suivi de symboles… La coloration syntaxique reste l'affaire de l'éditeur, je pense que des aller-retours là dessus seraient très mauvais pour les performances, surtout qu'il existe déjà des formats assez simples pour décrire la coloration syntaxique (https://kate-editor.org/syntax/ pour voir le format utilisé par Kate, implémenté également dans Qt Creator)
# Points de vue alternatifs
Posté par Pinaraf . Évalué à 10.
Tout d'abord, une remarque : Microsoft n'utilise pas LSP dans son «vrai» IDE. Ils ne l'utilisent que dans Visual Studio Code, qui reste un jouet comparé aux fonctionnalités de Visual Studio.
Il y a quelques années, une étudiante avait commencé à travailler sur le support de Rust dans KDevelop, et avait étudié la possibilité d'utiliser LSP. Son article était très intéressant là dessus : https://perplexinglyemma.blogspot.com/2017/06/language-servers-and-ides.html
D'autres développeurs se sont penchés dessus depuis, et si rien n'a été fait côté KDevelop (pour les raisons mentionnées avant je suppose) une intégration est désormais possible dans Kate https://kate-editor.org/posts/kate-language-server-protocol-client/
Donc LSP… c'est "bien", mais ça ne fait pas tout. Si tous les IDEs libres se limitaient demain à LSP, on perdrait énormément sur les fonctionnalités les plus avancées nécessitant que l'IDE comprenne le langage de programmation manipulé.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à 4. Dernière modification le 19 mai 2021 à 11:08.
Rien que sur le C#, voici pourquoi j'utilise VS plutôt que VSCode:
je sais pas si c'est lié à LSP, mais ça fait des années que ça dure.
Donc là c'est déjà naze. Mais si je rajoutes l'absence de CodeMaid (pour le linting) et Codist (pour la documentation à l'écran améliorée, notamment) (qui sont des extensions qui n'existent que pour VS), alors là ça devient:
et puis c'est tout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Points de vue alternatifs
Posté par ff9097 . Évalué à 2.
C'est vrai que j'ai abandonné VSCode parce qu'à chaque fois la complétion finit par ne plus fonctionner (ou avec une grosse latence). Idem pour un simple renommage de fichiers/fonctions/variables…
[^] # Re: Points de vue alternatifs
Posté par Elfir3 . Évalué à 5.
Si c'est toujours le cas, ce doit être spécifique à l'implémentation C#.
Je sais que le serveur rust fournit pas mal de fonctionnalités de génération et refactoring, au moins via les assistants. Ex: https://rust-analyzer.github.io/thisweek/2021/04/26/changelog-74.html
Pour la doc: https://user-images.githubusercontent.com/11014119/112712565-6eb99380-8f0b-11eb-88de-5d7f974dfe6d.png
Et la complétion est au chocolat…
[^] # Re: Points de vue alternatifs
Posté par Pinaraf . Évalué à 4.
Dans mon cas, j'utilise KDevelop pour du C++.
Des fonctionnalités majeures de cet IDE qui seraient perdues par LSP aujourd'hui :
- coloration sémantique du code : utilisation d'une palette de couleurs pour les variables dans une fonction, qui permet en parcourant rapidement le code d'avoir une lecture plus rapide grâce aux variations de couleur
- expansion des macros : bien que je sois heureux aujourd'hui de ne plus avoir à toucher à un monstre de macros que j'ai affronté dans un emploi précédent, je tombe encore dans des projets sur des usages intensifs des macros, et avoir l'IDE qui affiche la traduction de la macro, ça aide beaucoup
- hiérarchie des classes dans un projet
Demain, LSP pourrait implémenter tout ça je pense, mais avec plusieurs évolutions du protocole, et ça sera avec un coût : soit l'IDE reprend en mémoire l'ensemble des éléments (grosse duplication), soit il va y avoir un ping-pong permanent avec le serveur (latence).
[^] # Re: Points de vue alternatifs
Posté par gagbo (site web personnel) . Évalué à 4.
D'après ce que je comprends tout ça existe déja dans LSP. Des images d'emacs-ccls qui montrent ces usages :
https://github.com/MaskRay/emacs-ccls
L'expansion de macros a l'air manquante ici (on n'a que les
#if / #endifgrisés en fonction du préprocesseur), mais la coloration arc-en-ciel par nom de variable est présente, la hiérarchie des classes/méthodes est accessible, et on peut naviguer de référence de variable en référence de variable, en fonction de si c'est un écriture/lecture etc.Et surtout, rien n'empêche d'utiliser LSP et autre chose si on le souhaite de toute façon.
J'ai pas l'impression que la consommation mémoire sera démentielle non plus, c'est le serveur LSP qui a une grosse consommation RAM pour comprendre le code qu'il analyse, l'éditeur n'a rien de très intensif à faire dessus
J'imagine qu'en utilisant JSON-RPC via des sockets pour communiquer, LSP sera toujours plus lent (en termes de latence) que si une grosse entreprise paie des ingénieurs pour avoir un EDI énorme où toutes les structures de données nécessaires sont en RAM dans le même process. Ne serait-ce que sur la sérialisation/déserialisation des messages.
Mais ça permet aussi d'éviter le «vendor lock-in», et de tester très facilement un nouveau langage (comme Zig ou Julia ou n'importe) depuis son éditeur sans avoir 5 semaines de configuration/recherche d'éditeur à faire.
[^] # Re: Points de vue alternatifs
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Avant ça, moi je vois ce paragraphe qui compléte concrètement le suivant que cite
Pour la génération de code, c'est peut-être en rapport avec son usage de Rust ?
Et pour son opinion, c'est certainement lié à son expérience avec un EDI non nommé ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Points de vue alternatifs
Posté par bbo . Évalué à 5.
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) :
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 :
[^] # Re: Points de vue alternatifs
Posté par Xarkam (site web personnel) . Évalué à 3.
C'est vrai en 2018 le support de razor/asp n'était pas complet/implémenté.
En 2021, dans vscode, il est possible d'ouvrir des fichiers razor avec la bonne coloration syntaxique et le reste qui va avec.
J'utilise au quotidien vscode/Rider. vscode lorsque je veux faire une édition rapide et rider pour les fonctions avancées qu'on retrouve dans R# ou alors le décompilateur.
En 2021, avec vscode et l'extension C#, il est tout à fait faisable de faire par exemple des applications blazor avec un très bon support.
Je pense que LSP a vraiment un bel avenir devant lui si on n'en fait pas un mamouth et qu'on ne cherche pas à en faire plus que ce pour quoi il a été prévu.
[^] # Re: Points de vue alternatifs
Posté par Tit . Évalué à 2. Dernière modification le 20 mai 2021 à 08:32.
C'est quoi razor, rider, R#
bon razor j'ai trouvé (https://fr.wikipedia.org/wiki/ASP.NET_MVC#Razor), mais le reste ?
[^] # Re: Points de vue alternatifs
Posté par Xarkam (site web personnel) . Évalué à 2.
Rider, c'est Jetbrains Rider et R# c'est Jetbrains Resharper.
Des outils dédiés au développement C#.
Le premier est in IDE multiplateformes et le second un addon à Visual Studio.
[^] # Re: Points de vue alternatifs
Posté par Uther Lightbringer . Évalué à 8.
L'article est quand même bien daté et une bonne partie n'est plus trop pertinente au regard de la situation actuelle. A l'époque, le LSP et son implémentation en Rust(RLS) étaient encore a leur début. Depuis, RLS a été supplanté par rust-analyser : une nouvelle implémentation from scratch conçue spécifiquement pour l'analyse rapide de source, même incomplet, ce qui est bien mieux taillé pour les IDE. De plus le protocole LSP s'est aussi étoffé et offre plus de fonctionnalités, notamment pour mieux gérer un projet dans son ensemble.
Le seul IDE qui à fait le choix du plugin Rust spécifique et qui s'est donné les moyens de le maintenir est Intellij IDEA/CLion. Il faut reconnaitre que c'est un travail de qualité mais qui n'est clairement pas a la portée de la plupart des mainteneurs d'IDE. De nos jours, le support de Rust dans Kdevelop n'est plus maintenu alors que tous les éditeurs qui supportent le LSP ont une gestion plutôt bonne du Rust quasiment au niveau d'Intellij IDEA.
[^] # Re: Points de vue alternatifs
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est un jouet si tu compares les fonctionnalités sortie de boîte, mais pas une fois installé les plugins nécessaires à ton flux de travail et les langages et plateformes sur lesquelles tu travailles.
Et c'est utilisé par des ingénieurs dans le monde entier, y compris travaillant pour microsoft.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à 4.
Bah non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Points de vue alternatifs
Posté par Xarkam (site web personnel) . Évalué à 1.
Pour ce qui est de la complétion aux fraises, je n'en ai jamais fait l'expérience (et j'utilise vscode depuis des années)
Pour ce qui est du reste, je te dirais que moi qui ai R#, Visual Studio de base c'est un gros outil bien pauvre si on n'y adjoint pas R#.
Mais bon, je suis passé sur Rider car Visual Studio 2019 avec R# c'est lourd dingue à charger. Sans compter qu'une solution avec plein de projet ça ralenti encore plus le process d'ouverture et d'analyse.
Pour ce qui est de vscode, oui avec quelques extensions on a un outil très propre et non il ne te fera jamais des propositions de refactoring de code (par exemple var du linq) car ce n'est pas un IDE.
vscode est un éditeur de code et pas un IDE. Donc nul besoin de comparer les deux.
Cependant, si je dois modifier un fichier source dans quelque chose d'existant, je ne vais pas perdre mon temps à ouvrir toute la solution dans VS, je vais juste l'ouvrir dans vscode et faire la modif. Ça me fera gagner un temps énorme.
Si je veux faire de l'optimisation de code et du refactoring, là j'utiliserais un IDE pour profiter de l'analyse de code qu'il apporte.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à 0. Dernière modification le 19 mai 2021 à 22:49.
On est d'accord.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Points de vue alternatifs
Posté par Elfir3 . Évalué à 4.
Ça dépend de l'implémentation lsp pour le langage. Pour rust (via rust-analyzer) fait des propositions de refactoring. Voir les assistants ici par exemple : https://rust-analyzer.github.io/thisweek/2021/04/05/changelog-71.html
[^] # Re: Points de vue alternatifs
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est ton avis de dev C# qui ne s'applique pas forcément à tout. Même si je ne l'utilise pas/plus moi-même je connais pleins de dev super contents avec vscode. Il n'est pas équivalent à Visual Studio mais ce n'est pas le but.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à 0.
Des fonctionnalités de base qui font perdre un temps fou car elles manquent ou marchent pas, c'est OK car c'est pas la même philosophie ?!
Sauf que la preuve que non.
Donc bon… On vous donne des faits, et vous répondez "oui mais ça compte pas".
C'est juste chiant ce genre de réponses qui n'apportent rien.
OK, je reste sur Visual Studio alors. Je suis là pour bosser, pas pour perdre mon temps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Points de vue alternatifs
Posté par Xarkam (site web personnel) . Évalué à 1.
Encore une fois, les fonctionnalités de base qu'on attends sont subjectives à chacun.
Je trouve que vscode a quand même pas mal de fonctionnalités de base.
Je vais jouer la mauvaise fois (tu en fait un peu toi-même)
Visual Studio n'est pas un bon éditeur de code. Je ne peux pas éditer du Rust, Go, Php, Python ou Ruby de base.
Je ne peux faire que du C/C++ et C#. (Je ne parle pas html/css volontairement)
Je suis obligé d'y adjoindre Resharper pour avoir de vraies fonctionnalités.
Et cela sans compter qu'il faille attendre le bon vouloir de MS pour intégrer des choses basiques que tout le monde utilise ailleurs. (coucou .editorconfig)
Professionnellement, ça devient tellement courant de voir des devs coder le front avec vscode par ce que c'est vraiment un must et utiliser des IDE pour le back. (La mode étant aux api REST pour le back et du javascript pour le front)
Tu mets en avant la complétion qui est aux fraises. Perso je l'utilise plusieurs heures par jour et je n'ai absolument pas de problème de complétion. J'ai mis les extensions qui me facilite la vie.
Cela fait maintenant presque un an et demi que ma femme est en télétaff et donc travaille dans mon local pro avec moi. Sur toute cette période, je ne l'ai jamais entendue râler sur vscode. En revanche sur Visual Studio, c'est tellement fréquent que je n'y prête plus attention.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à 0. Dernière modification le 20 mai 2021 à 23:09.
Et le refactoring inexistant, on en parle ?
Ou c'est acceptable comme perte de temps colossale parce que "ce n'est pas un IDE" ?
(la vérité est que ça dépend de la qualité du plugin utilisé… comme quoi !)
(c'est fou ce qu'on peut excuser quand on aime)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 20 mai 2021 à 23:34.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Points de vue alternatifs
Posté par barmic 🦦 . Évalué à 3.
Et donc pas particulièrement de LSP.
C'est pas surprenant que la seule boite qui s'intéresse à C# cherche plus à proposer le truc le mieux fini avec son produit chère qu'avec son produit gratuit (et réutilisable avec autre chose que ces produits).
Je suis un habitué d'intellij/java ce qui doit être l'un des environnements les plus sophistiqués dans le domaine et dès que je quitte java je préfère vscode qui fait très bien le taff et je sais ce qu'est le refactoring.
Jetbrain et les équipes de Visual Studio ont tout à perdre à participer à LSP et ils ont des années d'avance pour faire cela. Néanmoins tout le reste de l'industrie se lance avec enthousiasme dans LSP et c'est une architecture amplement supérieure aux 2 autres. Qu'il y ai encore des soucis dans le design du protocole ou dans des plugins ça ne fait aucun doute, mais c'est clairement le sens de l'histoire. Jetbrain tente de maintenir son avance autant que possible et se rangera quand il perdra la course et pour VS ça dépend de qui hors de chez MS est intéressé par faire du tooling .Net.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Points de vue alternatifs
Posté par Xarkam (site web personnel) . Évalué à 1.
Oui refactoring inexistant par ce que oui, il n'y a jamais eu de de la part de vscode la prétention d'avoir du vrai refactoring.
Il serait ptet temps d'arrêter de comparer de l'eau et du vin.
Oui la qualité du plugin est primordiale. C'est aussi la voie choisie pour vscode, passer par des plugins.
Et si tu regardes la doc de vscode sur le refactoring, on t'indique qu'il existe des extensions qui ont du refactoring et comment les trouver. L'extension c# n'en fait pas partie.
[^] # Re: Points de vue alternatifs
Posté par xcomcmdr . Évalué à -2.
Oh, mais c'est lojn d'être propre à C#, hein.
C'est dommage, car sans ça vscode est un jouet.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Points de vue alternatifs
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Un jouet que tout le monde utilise :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Points de vue alternatifs
Posté par jyes . Évalué à 8.
VSCode is the new Sophie la Girafe.
# Ça existait… en Lisp
Posté par dzecniv . Évalué à 5.
Je partage car j'ai mis du temps à m'en rendre compte: les IDE Common Lisp, notamment Emacs & Slime mais pas que (maintenant SLIMA pour Atom est très bien), font déjà tout ça depuis… des décennies (avec une réserve sur le ré-usinage).
On a en effet: un serveur (Slynk) connecté à l'image Lisp en train de tourner, qu'on modifie à la volée pendant qu'on développe, et un client (Slime) connecté à l'éditeur. Toutes les infos décrites dans la dépêche existent de base dans l'image: les références croisées (qui appelle, qui modifie, qui est appelé par, qui référence qui), la validation est faite à la volée quand on compile notre code (on peut compiler la fonction sur laquelle on travaille, on a donc un retour immédiat avec variables non déclarées, mauvaises inférences de type, code inaccessible etc), la documentation etc.
Le tout de manière très fluide (alors qu'avec mon IDE Python…). Bref, c'est vraiment agréable à l'usage, c'est bon à connaître.
[^] # Re: Ça existait… en Lisp
Posté par claudex . Évalué à 10.
Ce n'est pas le premier. L'intérêt ici, c'est d'avoir une spécification cross-langage utilisée par plusieurs IDE et langage, ce qui veut dire que n'importe quel IDE peut prendre en charge n'importe quel langage facilement. Et inversément, n'importe quel langage peut écrire son serveur qui pourra être utilisé facilement ailleurs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Ed(1)
Posté par Xavier Maillard . Évalué à 1.
Avant j'utilisais des éditeurs kikoolol (genre emacs) mais maintenant, j'utilise le seul véritable éditeur: Ed(1).
Rapide comme l'éclair, ne me prend pas toute ma RAM/CPU pour tourner, ne se met pas dans mes pattes pour un oui ou pour un non.
Pas de configuration, le kiffe !
(Ok, on ne peut clairement pas faire ce que propose toute la panoplie des IDE mais je m'en passe très bien :p)
[^] # Re: Ed(1)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Je l'utilise encore fréquemment, et ce qu'en son absence que je lance Ex.
Ça c'est quand j'ai juste besoin d'un éditeur de texte (la plupart du temps, quasiment tous les jours.)
Quand j'ai besoin d'un EDI, j'ai ViM installé (c'est plus are car je ne suis pas "dev", mais j'ai des sessions parfois.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ed(1)
Posté par barmic 🦦 . Évalué à 3.
Tu installe quoi pour l'un comme pour l'autre ? Je n'ai pas ed et ex chez moi pointe sur vim et c'est juste vim lancé en mode ex par défaut (mais quand on passe en mode visual c'est clairement vim complet qui est lancé).
Je ne me souviens plus de ed, mais quel est l'intérêt de ex ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ed(1)
Posté par Clément V . Évalué à 2.
Étrange, c'est souvent dans le système de base. Sur Fedora, c'est le paquet
ed.Normal, ex c'est vi et, de nos jours, vi c'est vim.
À éditer des textes sans s'encombrer de fonctionnalités inutiles comme voir le texte qu'on est en train d'éditer.
[^] # Re: Ed(1)
Posté par barmic 🦦 . Évalué à 2.
C'est une façon de travailler son palais mental ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ed(1)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
« distraction free » pour de vrai.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ed(1)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
J'ai constaté que ça ne l'est plus dans de nos jours, dans GNU/Linux. Je pense que c'est parce-que les mainteneurs de distros pensent qu'on n'a plus les contraintes de place d'avant (plus personne n'utilise de disquette rescue mais on a plutôt des liveCD maintenant) et que Vi est la base (en même temps, je crois bien que sa présence est exigée dans POSIX mais pas celle de Ed qui est standardisé aussi)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ed(1)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ex c'est Ed étendu de fonctionnalités (extended) en maintenant la compatibilité.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Éditeur de texte / IDE
Posté par swilmet . Évalué à 4.
Je vois la différence entre un éditeur de texte et un IDE différemment.
Pour moi un IDE est un éditeur de texte (le composant principal) plus d'autres outils qui ont été intégrés :
- Compiler/faire tourner le code (au lieu de le faire dans un terminal).
- Git/gestionnaire de versions, mais de manière graphique.
- Un navigateur d'API, pour lire la doc.
- Un débogueur.
- Etc.
Mais rien n'empêche à un éditeur de texte d'avoir une auto-complétion intelligente, avec donc une connaissance du langage en question. Pareil évidemment pour la coloration syntaxique, etc.
[^] # Re: Éditeur de texte / IDE
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tout à fait d'accord. D'ailleurs, plein d'éditeur des premiers EDI n'ont pas toutes ces fioritures. Qui se souvient de : Dartmouth BASIC ; Turbo Pascal sur CP/M (je crois que la coloration est arrivée avec la version 2 pour DOS, et l'aide sur le langage via la touche F1 dans la version suivante) ; etc.
Jusqu'à une époque pas si lointaine, les EDI qui étaient assez sérieux permettaient d'utiliser l'éditeur de son choix (après tout, leur boulot est d'intégrer différents composants en un environnement de travail.)
Je ne sais pas ce qui est entendu par « de manière graphique » mais on a toujours travaillé en console/terminale avant l’avènement des fenêtres X, et les EDI existaient en CLI aussi.
Pour la compilation, c'est en tâche de fond ou dans un terminal voisin/incrusté, et le vrai plus est la liaison avec le code source en cas d'erreur. L'exécution et le débogage t'ouvrent toujours un terminal fils (ou une fenêtre modale de nos jours) ; c'est juste ça gère les bascules et préserve l'espace de travail en cours…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Éditeur de texte / IDE
Posté par swilmet . Évalué à 4.
De manière graphique : GUI, pas en CLI. Mais ça pourrait être en ncurses dans un terminal aussi. Ne pas confondre CLI (lignes de commandes), avec une interface style ncurses.
C'est vrai que de nos jours quand on parle d'un IDE, on a tendance à penser à une seule grosse application GUI qui sait tout faire.
Mais, en GUI, rien n'empêche de développer des applications séparées, mais qui communiquent entre-elles avec un mécanisme d'IPC. L'avantage est que chaque application a une GUI plus simple, et ça fait donc moins « usine à gaz ».
Exemple (dont j'ai participé au développement) : Devhelp (navigateur d'API), qui sait être utilisé séparément, ou alors être lancé par l'éditeur de texte (pour voir la doc d'une fonction ou d'un autre symbole) ou être intégré à un IDE (il y a pour ça la libdevhelp, en GTK).
Perso j'adore le fait d'appuyer sur un raccourcis clavier depuis mon éditeur de texte, pour sauter vers la doc correspondante dans Devhelp (pour le symbole qui se trouve sous le curseur dans l'éditeur de texte). Puis un simple Alt+Tab pour revenir à l'éditeur de texte. Simple mais efficace.
[^] # Re: Éditeur de texte / IDE
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je me suis permis le raccourci parce-que pour toutes les personnes qui ne jurent que par la IUG/GUI c'est de la ligne de commandes ; mais je faisais bien allusion à la IUT/TUI (ou de style Curse —avec une telle bibliothèque ou pas.)
Voilà, dans l'imaginaire collectif (que les éditeur ont donc réussi à imposer), un EDI/IDE est une application qui ferait tout… (pour les devs j'entends.) C'est probablement une insistance sur le I par lequel ces solutions veulent être le seul point d'entrée Incontournable ; mais on oublie le E qui veut que ce soit quelque chose de modulable et adaptable (la "customisation" ne prend pas en compte de pouvoir remplacer des morceaux par d'autres mais passe par un système d'extension/greffon spécifique et l'illusion est faite.)
Je n'utilise pas Devhelp mais bravo. Et ça va dans le sens unixien d'avoir des trucs dédiés et spécialisés et de pouvoir les combiner avec les autres. C'est effectivement
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Éditeur de texte / IDE
Posté par barmic 🦦 . Évalué à 3.
Et c'est précisément l'intérêt de LSP.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Cadeau c'est pas le bon mot
Posté par bnurb . Évalué à 0.
Jamais M$ ne fera de cadeau, a moins qu'il y ait des $$$ à la clé.
Ma théorie est qu'ils veulent exploiter la communauté pour implémenter des features top moumoute pour leur IDE semi-libre, truffé de tracker, qui finira sûrement coincé dans leur cloud proprio.
Bref c'est sympa, mais il ne faut pas perdre de vu que M$ est une entreprise hostile à nos liberté, et ce peu importe sa stratégie marketing de façade.
# Autre front-end LSP
Posté par Etienne Juliot (site web personnel) . Évalué à 3.
Je rajoute qu'il y a d'autres éditeurs Open Source qui supportent LSP :
* Theia : https://theia-ide.org/ , un éditeur web qui peut aussi servir de plateforme pour des IDE
* Che : https://www.eclipse.org/che/ , un IDE qui s'appuie sur Theia et qui y rajoute une notion de workspace de travail et des outils supplémentaires, notamment pour Kubernetes
* LSP4E : https://projects.eclipse.org/projects/technology.lsp4e , il fournit des éditeurs génériques intégrés à Eclipse pour intégrer LSP (à la fois la partie éditeur et debug). C'est d'ailleurs leadé par un français, Mickael Istria. C'est utilisé au coeur de Wild Web Developer https://projects.eclipse.org/projects/tools.wildwebdeveloper , qui fournit des éditeurs Web (CSS, HTML, JSon, JavaScript, TypeScript…).
[^] # Re: Autre front-end LSP
Posté par Pinaraf . Évalué à 3.
# Pour le C++ soyez très méfiant envers votre IDE
Posté par reno . Évalué à 7.
J'utilise principalement VSCode+grep pour travailler.
Pourquoi VSCode? Parce qu'il démarre assez rapidement et que la navigation entre ~20 fichiers est assez bonne la "plupart" du temps.
Pourquoi grep? Car souvent l'indexation de VSCode est pourrie (en C++): incapable de trouver un fichier sous un #include, ou il met + de temps que grep pour me trouver la définition d'une fonction(!) ou pire il me donne la mauvaise définition d'une fonction (dans le mauvais working tree).
Mais j'étais resté confiant en l'indexation de CLion (que je n'utilise pas car trop lent), sauf que cette semaine en faisant un find usage d'une méthode j'ai découvert que CLion avait manqué l'appel a la méthode a certains endroits..
Ma conclusion : un bon éditeur de texte plus grep/ag/ripgrep >> aux IDE pour les gros projets C++
Dommage que je n'ai pas le temps d'apprendre a configurer correctement VSCode pour qu'il appelle grep ou find pour moi, plutôt que de le faire moi même dans un terminal et de lui dire ensuite d'ouvrir le fichier que j'ai trouvé (ce qui est totalement absurde quand on y réfléchit bien)
[^] # Re: Pour le C++ soyez très méfiant envers votre IDE
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
[trolldi]
Chuut, tu vas froisser les aficionados…
[/trolldi]
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour le C++ soyez très méfiant envers votre IDE
Posté par swilmet . Évalué à 3.
Pour le C il y a l'outil Cscope que j'utilise de temps en temps, mais la plupart du temps un petit
git grepfait très bien l'affaire, en effet :-)Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.