L'expansion de macros a l'air manquante ici (on n'a que les #if / #endif grisé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 gagbo (site web personnel) . En réponse à la dépêche LSP (Language Server Protocol). É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.