URL: https://linuxfr.org/users/trim/journaux/transformer-vim-en-ide-avec-lsp-et-dap Title: Transformer vim en IDE avec LSP et DAP Authors: Adrien Dorsaz Date: 2020年12月02日T22:58:21+01:00 License: CC By-SA Tags: vim, ide, vscode, langage_server_protocol, lsp, debug_adapter_protocol et dap Score: 49 Cette année, j’ai découvert l’IDE Visual Studio Code, enfin, son pendant libre [VSCodium](https://vscodium.com/) pour mon travail. C’est un IDE qui fonctionne plutôt bien, mais je ne me sentais pas très à l’aise avec le fait que l’upstream (Microsoft en l’occurrence) distribue des binaires sous [licence non open-source](https://code.visualstudio.com/license) et ajoute de la télémétrie par défaut. En plus, c’est développé avec `Electron` et, bien que j’aime beaucoup utiliser _nodejs_, je trouve vraiment lourd d’avoir un Chrome complet lancé juste pour mon _IDE_. D’un autre côté, j’aimais bien utiliser _vim_ comme éditeur de configuration et de petits textes sur mon serveur. J’avais tenté plusieurs fois de configurer _vim_ comme IDE, mais j’ai eu pas mal de peine à comprendre comment ajouter et activer des plugins. En fait, si on regarde le site [vimawsome](https://vimawesome.com/plugin/ctrlp-vim-red), on voit déjà listé 4 gestionnaires de plugins différents pour _vim_. J’étais un peu perdu aussi par Debian qui empaquette des plugins et propose en dépendance [vim-addon-manager](https://packages.debian.org/fr/buster/vim-addon-manager) pour activer les plugins installés. Bref, j’ai essayé plusieurs fois de configurer _vim_ et je n’ai pas réussi. Cette année, j’ai appris que, depuis la version 8 de _vim_, il y a un gestionnaire de paquet officiellement supporté et activé par _vim_ ! En plus, il permet d’activer les plugins très simplement: 1. Créer un "pack" où l’on va installer nos plugins : `mkdir – p ~/.vim/pack/adrien/{start, opt}` (les plugins dans `start` sont actifs dès le démarrage de _vim_, ceux dans `opt` s’activent avec la commande `: packadd`) 2. Installer un plugin dans ce répertoire, par exemple pour `ctrl-p` (la recherche de fichiers): ```sh cd ~/.vim/pack/adrien/start; git clone https://github.com/kien/ctrlp.vim ``` Bon, une recherche aisée dans les fichiers, c’est un bon début pour un IDE, mais ça n’est clairement pas suffisant. Un des gros apports de Visual Studio Code est son système [_Language Server Protocol_](https://en.wikipedia.org/wiki/Language_Server_Protocol) (_LSP_) qui permet de partager entre les différents _IDE_ l’analyse syntaxique et les aides au développement pour chaque langage de programmation. En théorie, c’est beau, mais je ne l’avais pas encore vraiment vu appliqué. Eh bien, j’ai découvert que le plugin [coc.nvim](https://github.com/neoclide/coc.nvim) permet de faire le lien entre _vim_ et les différents _LSP_ développés pour _Visual Studio Code_ (en général, sous licence MIT par Microsoft). Le truc, c’est que, les _LSP_ développés pour _Visual Studio Code_ sont développés sous forme d’extensions indépendantes de _Visual Studio Code_ et, du coup, _coc.nvim_ propose de faire l’interface entre _vim_ et les extensions utilisées par _Visual Studio Code_. Oui, vous avez bien suivi, j’ai commencé par dire que j’étais perdu avec les multiples gestionnaires d’extensions de _vim_ et, là, je viens de proposer un plugin qui installe ses propres extensions avec son propre gestionnaire. C’est une belle mise en abyme que j’aurais préféré éviter, mais qui fonctionne bien, ma foi ! Il est à noter également, que le plugin _coc.nvim_ dépend de _nodejs_ et _npm_, ça ajoute donc quand même pas mal de dépendances à un « simple vim ». Mais comme je travaille déjà avec ces technologies, ça ne m’a pas posé plus de problèmes que ça. Bien, maintenant, j’ai un _vim_ capable de chercher rapidement des fichiers dans le dossier courant et de m’aider à programmer selon les types de fichiers. C’est déjà bien, mais il me manque encore un outil très important : le débugueur pour inspecter ce qui se passe dans mon code facilement. J’ai travaillé un temps avec _Visual Studio Code_ ouvert presque uniquement pour l’outil de debug, mais ce n’était pas vraiment pratique. À force de chercher un moyen de debug du _nodejs_ dans [vimawsome](https://vimawesome.com/), je comprends enfin que je peux utiliser l’excellent [Vimspector](https://github.com/puremourning/vimspector) (même si ce n’est pas bien indiqué dans le README, il supporte node ≥12 avec l’adaptateur _vscode-node-debug2_). Grâce au fichier [README](https://github.com/puremourning/vimspector#background) de _Vimspector_, j’apprends que _Visual Studio Code_ a aussi développé un protocol pour les débugueurs nommés [_Debug Adapter Protocol_](https://microsoft.github.io/debug-adapter-protocol/)(_DAP_) dans la même veine que _LSP_, mais dédié au debug des langages. Du coup, j’ajoute encore un système de plugin dans mon IDE (en plus de celui de _vim_ et de _coc.nvim_), mais à nouveau, ça marche bien et ça me permet de me familiariser avec une seule interface de debug pour plusieurs langages de programmation. Il faut savoir que pour pouvoir utiliser _Vimspector_, il faut avoir une version de _vim_ très récente (version au moins 8.2), compilé avec le support de python 3.6 au moins. Finalement, j’ajoute encore quelques pugins à _vim_ pour afficher de belles couleurs (_oceanic-next_) et utiliser les fichiers `.editorconfig` (_editorconfig-vim_) et j’ai un IDE qui me plaît beaucoup et qui me semble reste léger malgré tous ces ajouts. Depuis que j’utilise _vim_ plus intensément, j’ai découvert ces fonctionnalités vraiment sympa: * la commande `:term` (ou `:terminal`) pour faire un `split` du buffer actuel et afficher un buffer avec un terminal. C’est très pratique pour rester avec la session _vim_ ouverte avec tous les fichiers en cours de modification et pouvoir lancer quelques commandes _git_, _meson_ ou _ninja_. * les popups (nommés _popovers_ dans GTK) d’aide que _coc.nvim_ peut afficher directement sous la ligne active si _vim_ est assez récent * les raccourcis claviers très pratique comme `gd` (go to definition), `"+y` (pour copier depuis _vim_ vers le presse-papier graphique)... * la commande `:ls` pour lister les fichiers ouverts et `:b 1` pour afficher dans le buffer courant un des fichiers ouverts * les onglets. En fait, les buffers et split des windows sont déjà très pratiques, mais les onglets sont aussi pratiques pour avoir plusieurs espaces de travail simultanés. _Vimspector_ en fait un très bon usage : dès qu’une session de debug est démarrée, _Vimspector_ ouvre un nouvel onglet avec plusieurs buffers organisés pour le debug. * la commande `:Lexplore` pour ouvrir une barre d’exploration sur la gauche et la [configuration](https://shapeshed.com/vim-netrw/) de `netrw` pour naviguer dans l’arborescence * le fait qu’un _vim_ local peut modifier des fichiers à distance grâce à SSH et `netrw` Enfin, comme j’ai commencé à utiliser aussi _vim_ pour mes projets persos, j’ai préparé un répertoire _git_ avec [mes fichiers de configuration](https://projects.adorsaz.ch/adrien/config/) si vous voulez tous les détails.

AltStyle によって変換されたページ (->オリジナル) /