Journal Transformer vim en IDE avec LSP et DAP

Posté par Adrien Dorsaz (site web personnel, Mastodon) le 02 décembre 2020 à 22:58. Licence CC By‑SA.

Étiquettes :

déc.

2020

Cette année, j’ai découvert l’IDE Visual Studio Code, enfin, son pendant libre VSCodium 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 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, 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 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):

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 (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 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, je comprends enfin que je peux utiliser l’excellent 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 de Vimspector, j’apprends que Visual Studio Code a aussi développé un protocol pour les débugueurs nommés 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 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 si vous voulez tous les détails.

# Terminal

Posté par barmic 🦦 le 02 décembre 2020 à 23:20. Évalué à 4.
Merci pour ton journal
- 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.
J'ai jamais trop compris l'intérêt. Tous les éditeurs mettent à un moment ou à un autre en avant ce genre de fonctionnalité. J'utilise énormément le terminal et je n'ai jamais vu de problème à utiliser mon urxvt. Pour un vim un Ctrl+z/fg ou un changement d'onglet de mon terminal font très bien l'affaire.

"+y (pour copier depuis vim vers le presse-papier graphique)…

Je devrais prendre l'habitude de l'utiliser mon :r!xclip -o est un peu bourrin.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Terminal
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 06:30. Évalué à 6.
  
  Je trouve utile le terminal intégré pour garder sous les yeux mon contexte avec le fichier que je suis en train d'éditer. Je ne l'utilise pas en permanence, c'est plutôt sporadiquement.
  
  C'est aussi très utile pour le débogueur: ça lui permet d'afficher la sortie sur le côté.
  - [^] # Re: Terminal
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 03 décembre 2020 à 23:04. Évalué à 1.
    
    Amateur de mettre l'éditeur en tâche de fond aussi (et ça a l'avantage de fonctionner avec les autres Vi, pas que ViM —car je suis amené à travailler sur autre chose que du Linux) Mais qu'entends-tu pas « sporadiquement » ?
    J'ai parfois des besoins que je qualifierai de sporadique (rare pour moi, et ponctuels surtout —donc pas besoin de mettre l'éditeur en tâche de fond car c'est juste une commande rapide avant de poursuivre mon édition.) Dans ce cas, j'utilise beaucoup :! (ça aussi c'est depuis le Vi historique)
    
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    - [^] # Re: Terminal
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 23:30. Évalué à 2.
      
      Par exemple, si je veux voir la liste des fichiers actuellement modifiés dans le projet avec git status, ça permet de les garder en face de moi.
      
      Avec les versions récentes de vim, depuis le terminal intégré, tu peux repasser aux autres window de vim avec Ctrl-W + flèches et continuer à travailler avec vim tout en gardant cette liste sous les yeux.
      
      Un autre exemple, est de faire un git grep (mais je viens de découvrir :vimgrep que je vais essayer de privilégier) ou juste un git diff pour être sûr des modifs que j'ai actuellement fait.
      
      Je connais aussi :! ou Ctrl-Z, mais le gros désavantage est que je perd tout ce que je suis en train de faire et ça me fait perdre du temps, parce que je dois continuellement changer de contexte, alors que là, j'ai tout sous les yeux et je peux interagir avec les deux: les fichiers en cours d'édition et le résultat de ma commande.
      - [^] # Re: Terminal
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 03 décembre 2020 à 23:52. Évalué à 2.
        
        Merci ; je comprends un peu mieux. En fait la différence est que j'ai rarement besoin de garder le contexte (je crois que ça m'est arrivé une fois et que j'avais utilisé une division horizontale de l'espace de travail de ViM) Et depuis un an et demie, je me suis mis à fugitive ^^
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: Terminal
  
  Posté par Anonyme le 03 décembre 2020 à 16:09. Évalué à 4. Dernière modification le 03 décembre 2020 à 16:09.
  Pour un vim un Ctrl+z/fg ou un changement d'onglet de mon terminal font très bien l'affaire.
  
  +1
  
  J’utilise Ctrl-Z/fg pratiquement tout le temps quand je dois rapidement éditer des fichiers¹ et si quand je développe quelque chose de plus complexe, je créé plusieurs « panes » dans tmux et je navigue avec préfixe + flèches directionnels.
  1. Ça m’a d’ailleurs souvent jouer des tours avec systemctl edit qui bloque complètement sur un Ctrl-Z, Thanks ~~Obama~~ Lenart. ↩
- [^] # Re: Terminal
  
  Posté par pulkomandy (site web personnel, Mastodon) le 03 décembre 2020 à 21:08. Évalué à 3.
  
  Une fonction que j'utilise pas mal est de lancer un "make" ou équivalent dans un terminal vim. Ce qui permet à vim de parser la sortie du make et de me surligner les erreurs dans les fichiers ouverts.
  
  Sinon ça me sert ponctuellement pour lancer une ou deux commandes (souvent un git grep pour retrouver un bout de code par exemple). Probablement parce que y'a plein de choses que je pourais faire directement avec des commandes vim, mais que j'ai jamais appris car j'ai l'habitude d'avoir un terminal.
  
  Enfin, c'est utile parce que la gestion des splits, onglets, et compagnie de vim s'applique aux terminaux. Certes, on pourrait aussi faire ça avec tmux, mais quand on a l'habitude des raccourcis claviers de vim, ça fait une chose de moins à mémoriser.
  - [^] # Re: Terminal
    
    Posté par barmic 🦦 le 03 décembre 2020 à 22:16. Évalué à 4.
    
    Une fonction que j'utilise pas mal est de lancer un "make" ou équivalent dans un terminal vim. Ce qui permet à vim de parser la sortie du make et de me surligner les erreurs dans les fichiers ouverts.
    
    Au cas où, la commande make de base pour ça (en tout cas dans mon vim sans plugin) c'est :make (et ça ne lance pas forcément make).
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Terminal
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 23:10. Évalué à 3. Dernière modification le 03 décembre 2020 à 23:10.
      
      Ah oui, j'avais vu :make, c'est sympa.
      
      Je viens de lire le :help make et de trouver juste en dessous :vimgrep qui est bien plus efficace que git grep, puisque la liste de résultat est interactive, merci beaucoup ! Je vois que :grep permet aussi de définir sa commande, je pense que je vais la définir avec git grep, parce que c'est assez cool le respect du fichier .gitignore.
      - [^] # Re: Terminal
        
        Posté par benoar le 04 décembre 2020 à 10:35. Évalué à 3.
        
        Je vois que :grep permet aussi de définir sa commande, je pense que je vais la définir avec git grep, parce que c'est assez cool le respect du fichier .gitignore.
        
        Perso je l'ai combiné avec la recherche du mot sous le pointeur pour obtenir un grep qui utilise soit "git grep" ou le grep standard en fonction d'où on est, avec ou sans respect de la casse ; le résultat arrive dans la fenêtre de quickfix et est navigable avec les raccourcis classiques. Et en plus, les recherches sont « stackées » et tu peux facilement revenir en arrière ou en avant. C'est une de mes principales manières de naviguer aujourd'hui :
        
        http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=.vimrc;h=3883be03f5353fd40b9d31a95a5a0d3a77ee083c;hb=refs/heads/work#l141
        
        Les raccourcis ici sont ,g (ou ,G). Tout ça a été adapté de codes trouvés ailleurs, mais j'aime bien mon intégration de l'ensemble.
# LanguageClient

Posté par Clément V le 03 décembre 2020 à 11:07. Évalué à 6.

J'ai pas essayé coc, ça a l'air un peu trop gros pour moi. Pour pouvoir utiliser LSP, j'ai installé LanguageClient-neovim. Il y a juste à lui dire quel serveur utiliser pour chaque langage, pas besoin d'installer nodejs.
- [^] # Re: LanguageClient
  
  Posté par Shuba le 03 décembre 2020 à 11:22. Évalué à 4.
  
  Un autre plugin vim qui sait faire LSP est YouCompleteMe. Je l'aime bien pour son interface de complétion très puissante même sur du simple texte.
  - [^] # Re: LanguageClient
    
    Posté par vieille_moule le 03 décembre 2020 à 11:43. Évalué à 3.
    
    J'adore VIM et je ne suis pas contre l'approche de MS d'utiliser un "serveur" pour mutualiser le code d'assistance au language et le debugging mais je trouve tout ça lourdingue, avoir un codebase complet avec leurs deps dans mon $PLUGDIR me fait tourner la tête.
    
    Et le capharnaüm YCM, LangageClient-neovim et coc-nvim n'aide pas.
    Car en plus, ce n'est pas si évident que ça à activer.
    
    Bref, j'ai toujours une solution bâtarde après 2 ans et je ne sais par quel miracle ça fonctionne ou non.
    
    Dès fois, je préfère simplement me passer de l'autocompletion.
    - [^] # Re: LanguageClient
      
      Posté par vieille_moule le 03 décembre 2020 à 12:16. Évalué à 3.
      
      ah, apparement neovim a eu la bonne idée d'intégrer un client LSP (issues) et a de bons retours (comme coc, ycm etc vous me direz).
      
      Mais le fait que ça soit intégré me rend plus enthousiaste et plus enclins à essuyer les plâtres.
      - [^] # Re: LanguageClient
        
        Posté par vieille_moule le 03 décembre 2020 à 13:54. Évalué à -4.
        
        Je retire ce que je dis pour neovim (HEAD)…
        
        Bon sang! C'est quoi ? .nvim ? .local/share/nvim ??
        init? init.vim ? init.nvim ?
        
        bon, voyons ce qui dit: https://github.com/neovim/nvim-lspconfig
```
Install

Requires Nvim HEAD/nightly (v0.5 prerelease). nvim-lspconfig is just a plugin. Install it like any other Vim plugin, e.g. with vim-plug: :Plug 'neovim/nvim-lspconfig' Call :packadd nvim-lspconfig in your vimrc if you installed nvim-lspconfig to 'packpath' or if you use a package manager such as minpac.

```Utilisez vim-plug qu'ils disent mais appelez la commande packadd du gestionnaire built-in… ce qui ne donne rien bien évidemment.
        
        20min à tourner en rond.
        
        BEN NON, c'est dans .config/nvim!
        
        J'arrive enfin à charger ce module pour apprendre que le langage que je voulais n'est pas encore supporté. :)
        
        J'en ai marre!
        
        Certes, je disais être prêt à essuyer les plâtres, mais je parlais du client lsp pas dés les 10 premières lignes de la documentation foireuse.
        
        Il ne faut pas que tout le monde se sente le besoin de faire du LL si il ou elle n'est pas prête à faire preuve d'un minimum de rigueur: TESTER LA DOC.
        
        Entre ça et pas de logiciel libre, je préfère pas de logiciel libre.
        
        Le NO WARRANTY c'est gentil mais si c'est pour faire perdre du temps…
    - [^] # Re: LanguageClient
      
      Posté par barmic 🦦 le 03 décembre 2020 à 12:33. Évalué à 8.
      
      J'adore VIM et je ne suis pas contre l'approche de MS d'utiliser un "serveur" pour mutualiser le code d'assistance au language et le debugging mais je trouve tout ça lourdingue
      
      En plus de mutualiser le code, ça permet aux développeurs de langage de fournir leur gestion sans avoir à s'interfacer avec tous les éditeurs existant et à ne pas dépendre des release de ceux-ci.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Et ça donne quoi coté réactivité?

Posté par reno le 03 décembre 2020 à 14:40. Évalué à 6.

Salut,

j'utilise actuellement VSCode pour développer en C++, mais bon j'en suis moyennement satisfait, alors j'ai essayé SpaceVim et non seulement il y avait des bugs au démarrage en plus SpaceVim s'ouvrait plus lentement que VSCode (à vide) --> poubelle.

D'ou ma question, ça donne quoi coté réactivité ta configuration?
- [^] # Re: Et ça donne quoi coté réactivité?
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 20:22. Évalué à 2.
  Hello,
  
  Je ne l'emploie pas sur un projet en C++, mais mon installation est assez réactive, parce que:
  1. vim n'utilise pas Electron et est lui-même assez léger
  2. vim n'indexe pas tous les fichiers du projet. Il fait juste de charger les fichiers que tu lui demandes, les transfert au LSP et reçoit les informations en retour.
    - La conséquence, est qu'il est bien capable de te rediriger vers la définition des méthodes utilisée dans le fichier actuellement ouvert (avec gd). Mais il est incapable de trouver toutes les références à cette méthode (avec gr), puisqu'il n'envoie pas tous les fichiers du projet à LSP. J'ai remarqué aujourd'hui, il trouve les références uniquement dans les fichiers que tu as ouvert actuellement.
  3. le plugin ctrl-p, que j'utilise pour trouver rapidement les fichiers, scanne vraiment rapidement le dossier du projet
  À priori, ça devrait donc être plus léger, mais je n'ai pas mesuré réellement et il y a quand même des fonctions en moins. Ce que je lève dans le point "2." par rapport à la recherche de référence, ça veut aussi dire que tu ne pourras pas faire de big refactor facilement (mais je m'en sors en général avec des git grep -iP). Mon curseur personnel pour l'instant c'est que je préfère avoir un IDE réactif, mais avec ces fonctionnalités en moins (que j'utilise rarement en réalité).
  
  Il faudrait que j'installe un Grafana et que je monitore l'utilisation CPU et mémoire pour les processus vim.
  
  PS: Pour C++, j'ai essayé sur un tout petit projet perso, et le LSP coc-clangd demande d'avoir clangd d'installé et de fournir le fichier compile_commands.json (crée par meson dans mon cas). D'une fois que je l'ai fais, ça a bien marché, mais le projet était tout petit :-)
  - [^] # Re: Et ça donne quoi coté réactivité?
    
    Posté par barmic 🦦 le 03 décembre 2020 à 22:18. Évalué à 3.
    
    Ce qui a tendance à ralentir vim, c'est les plugins qui ne sont pas asynchrones (ou qui ne l'ont pas était pendant longtemps).
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Et ça donne quoi coté réactivité?
    
    Posté par ff9097 le 03 décembre 2020 à 22:20. Évalué à 4.
    
    Donc en plus de ne pas rediriger vers les définitions de méthodes, j'imagine qu'il ne peut pas non plus faire l'inverse, afficher toute les utilisations dans le projet d'une méthodes, ou d'une variable.
    Je suppose donc aussi qu'on n'a pas de complétion ou de vérification temps réel sur les méthodes existantes ou sur les paramètres passés. Et l'import automatique ?
    Ce qui me semble quand même des fonctions de base que j'utilise beaucoup même sur des petits projets.
    Je ne suis pas spécialement étonné j'ai longtemps essayé de faire de vim un IDE digne de ce nom et en fait le problème est toujours le même. Ça reste très basique. Je ne suis pas sûr que l'efficacité de la saisie de texte sur vim ou sa légèreté justifie son utilisation sur un projet avec plusieurs fichiers. D'autant plus de beaucoup d'éditeurs proposent un mode vim.
    
    Bon par contre VSCode ce n'est pas tellement mieux. Sur le papier c'est beaucoup mieux. En pratique la complétion casse régulièrement, et le CPU n'en fait qu'à sa tête. J'ai testé avec plusieurs langages. Je ne comprends pas l'engouement.
    
    En fait rien ne vaut les IDE Jetbrains. C'est les gros bouzins comme on les imagine : lourd en RAM, du temps pour tout indexer au démarrage… Mais on sait pourquoi : tout fonctionne out of the box et c'est très stable. Bon ils ne sont pas tous open source
    - [^] # Re: Et ça donne quoi coté réactivité?
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 22:53. Évalué à 2.
      
      Donc en plus de ne pas rediriger vers les définitions de méthodes, j'imagine qu'il ne peut pas non plus faire l'inverse, afficher toute les utilisations dans le projet d'une méthodes, ou d'une variable.
      
      Ce que je voulais dire, c'était ça justement: il peut te rediriger vers les définitions (LSP sait lire les include/require et te redirige), mais il ne peut pas te donner toutes les références, tant que les fichiers n'ont pas été ouvert.
      
      Je suppose donc aussi qu'on n'a pas de complétion ou de vérification temps réel sur les méthodes existantes ou sur les paramètres passés. Et l'import automatique ?
      
      D'expérience, la complétion fonctionne, quand tu as fais le bon import.
      
      L'import automatique peut fonctionner si tu as déjà ouvert le fichier dans ta session.
      
      Là, je te parle d'expérience avec un projet en nodejs, ça dépend sûrement du language server, mais ça semble assez trivial pour C++ aussi si les include ont bien été définit et que le fichier compile_commands.json a bien été construit.
      
      Ce qui me semble quand même des fonctions de base que j'utilise beaucoup même sur des petits projets.
      
      Si tu veux avoir ces fonctionnalités complètes, je pense que tu es obligé de passer par un scan complet des fichiers du projet et des dépendances, de tous les parser et de faire tenir ces informations en mémoire ou dans des indexes.
      
      Peut être qu'un plugin asynchrone (merci pour l'info barmic ;)) pour vim existe pour faire ça, mais je préfère me passer de ce genre de fonctionnalités, car je sais qu'elles seront bien trop consommatrices de ressources (CPU, mémoire et I/O disques).
    - [^] # Re: Et ça donne quoi coté réactivité?
      
      Posté par flan (site web personnel) le 03 décembre 2020 à 23:31. Évalué à 4.
      
      J'ai exactement le même sentiment.
      Je tape beaucoup moins vite avec un IDE Jetbrains qu'avec vim… mais en fait, je me suis rendu compte que c'était exactement ça : mes frappes clavier étaient beaucoup plus lentes.
      
      Avec le temps, j'ai surtout compris que j'ai besoin (à la grosse louche) de 10 à 20 fois moins de frappes clavier avec les IDE Jetbrains (je fais beaucoup de Python), et que mon code était beaucoup plus propre et avait de bonnes chances de fonctionner du premier coup (en tout cas, il ne comportera pas d'erreur de type, vu qu'elles sont détectées à l'écriture). Bref, tout en tapant plus lentement, je vais vraiment beaucoup plus vite avec un bon IDE qu'avec un vim que j'avais pourtant pas mal personnalisé.
# define IDE

Posté par Gil Cot ✔ (site web personnel, Mastodon) le 03 décembre 2020 à 23:18. Évalué à 1.

Salut,

Question un peu délicate : quelle est ta définition de « IDE » ? (je trouve que ça manque trop souvent dans beaucoup de journaux ici, et billets de blogs ou articles…)
Plus précisément (car je pense qu'on comprend tous « environnement de développement intégré » mais plus précisément) quels besoins as-tu et quels fonctionnalités recherches-tu en général pour apposer le tampon (IDE) et en particulier dans ton travail actuel (avec NodeJS si j'ai bien compris) ?

Merci.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: define IDE
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 03 décembre 2020 à 23:56. Évalué à 2.
  Hello,
  
  Ce qui m'importe dans un IDE, c'est de pouvoir m'aider avec:
  - de la complétion automatique des noms des variables, commandes… ça m'évite les fautes de frappe et ça aide à voir les arguments à passer
  - la recherche rapide des fichiers par noms incomplets
  - la prévention des erreurs de style en me donnant des indications à jour du linter que l'on a configuré (pour nodejs, on utilise eslint et il donne beaucoup de bons conseils)
  - pouvoir avoir plusieurs fichiers ouverts et affichés en même temps (les split de vim sont très bien pour ça)
  - pouvoir gérer les breakpoints et démarrer une session de debug
  - une fonction rechercher/remplacer qui comprend les expressions régulières
  - pouvoir naviguer dans le fichier facilement (vim est particulièrement efficace avec sa pléthore de moyen de navigations *, gd, :42, /texte, e, b…)
  Je me sens déjà bien à l'aise avec ces fonctionnalités.
  
  Après, je ne me cantonne pas à rester uniquement dans mon IDE, je n'hésite pas à ouvrir d'autres onglets dans le terminal pour utiliser des commandes extérieurs (git, grep, find, docker-compose…).
  
  Je ne souhaiterai pas que l'IDE devienne une usine à gaz et je préfère qu'il en fasse un peu moins, mais qu'il soie réactif.
  
  J'ai eu l'occasion de travailler avec des IDE qui ont beaucoup plus de fonctionnalités, comme Eclipse et Visual Studio Entreprise avec Resharper. J'ai eu vraiment de mauvais souvenir à cause de leur consommation excessive et constante de ressources pour que, de temps en temps, je puisse faire un refactor de malade qui va toucher une dizaine de fichiers ou trouver des références dans tout le projet (ce qui soit dit en passant peut aussi très bien être fait avec grep, find, awk et sed, c'est incroyable ces outils !).
  
  J'ai aussi eu l'occasion de travailler avec SQL Server Management Studio, où là c'est l'inverse: ce n'est quasiment qu'un éditeur de texte avec l'arborescence de la base de donnée à côté. C'était aussi clairement pas assez pour être efficace (même si on avait 1-2 plugins pour nous aider, c'était pas assez).
  
  Là, j'ai l'impression d'avoir atteint un juste milieu avec vim, LSP et DAP.
  
  D'ailleurs, Visual Studio Code n'en n'est pas très loin non plus, j'ai bien aimé travailler avec aussi et je les remercie d'avoir apporté LSP et DAP, c'est vraiment pratique pour tout le monde !
# Emacs

Posté par bruchieOP le 05 décembre 2020 à 09:13. Évalué à 0.

Essays aussi emacs avec son mode vim, c'est top, depuis que j'ai essayé c'est un autre monde complètement j'utilise cette distro d'emacs qui me donne presque exactement le meme feeling que vim https://www.spacemacs.org/
- [^] # Re: Emacs
  
  Posté par hocwp (site web personnel) le 05 décembre 2020 à 22:40. Évalué à 1.
  
  Et peut-être aussi doom-emacs : https://github.com/hlissner/doom-emacs/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.