J'utilise Vim, et vous ?

Ça fait plus de 10 ans que j’utilise Vim. Bizarrement je suis pas tant un power user que ça, je ne suis pas très bon en Vim Golf. Mais je suis tellement câblé pour utiliser mon petit subset des fonctionnalités de Vim que n’importe quoi d’autre ça ne marche pas.

Certains me diront de me diriger vers des outils comme VSC ou IntelliJ et d’y ajouter l’extension qui va bien pour avoir les fonctionnalités de Vim dans des outils plus modernes.

Idem. C’est juste pas du Vim J’ai envisagé de me mettre à NeoVim, pour 2024. Peut-être que c’est l’outil qui permet d’avoir le meilleur des deux mondes : véritable expérience Vim, mais avec des intégrations modernes (LSP) et un support de la souris ergonomique et totalement optionnel qui ne compromet pas l’expérience clavier pur.

La seconde est que les outils plus modernes sont conçus avec les interfaces modernes, donc avec l’utilisation de la souris.

J’avoue ne pas comprendre cet argument, très souvent invoqué par les afficionados de vim. Parce qu’il est faux.

Par exemple, IntelliJ (et les IDE JetBrains en général) se pilotent entièrement au clavier pour qui le souhaite. Et c’est pas faute pour l’éditeur de produire des ressources pour faciliter cette utilisation :

• Documentation : https://www.jetbrains.com/help/idea/mastering-keyboard-shortcuts.html
• Carte de référence des principaux raccourcis à imprimer : https://resources.jetbrains.com/storage/products/intellij-idea/docs/IntelliJIDEA_ReferenceCard.pdf
• Plugin (tiers mais référencé dans la doc officielle) qui indique quel raccourci clavier correspond à l’action qu’on vient de faire et permet d’en créer un directement si besoin : https://plugins.jetbrains.com/plugin/9792-key-promoter-x
• Billets de blogs sur les raccourcis méconnus : https://blog.jetbrains.com/idea/2021/08/10-places-you-don-t-need-to-use-the-mouse-in-intellij-idea/
• … et j’en passe.

Mais surtout, qu’un IDE qui n’est pas vim ne se comporte pas comme vim, même avec un plugin, c’est normal. Ça n’est en aucun cas un reproche que l’on puisse faire à cet IDE.

Les IDE modernes, à l’instar de vim, sont des outils complexes. Comme lui et comme tout outil, ils ont un mode de fonctionnement privilégié et nécessitent qu’on l’apprenne pour en tirer le meilleur. C’est tout à fait normal d’avoir des préférences – surtout sur des outils aussi importants au quotidien qu’un IDE pour un développeur – mais on peut exprimer ces préférences (ce qui est fait plusieurs fois dans ce billet) sans inventer des problèmes factices aux outils tiers.

J’avoue ne pas comprendre cet argument, très souvent invoqué par les afficionados de vim. Parce qu’il est faux.

Par exemple, IntelliJ (et les IDE JetBrains en général) se pilotent entièrement au clavier pour qui le souhaite. Et c’est pas faute pour l’éditeur de produire des ressources pour faciliter cette utilisation

L’argument qui est plutôt fait souvent est dans le reste du paragraphe que tu as tronqué. Les raccourcis claviers ne sont pas un substitut viable (pour un utilisateur de Vim) aux idiomes de Vim. En particulier, une des forces de Vim est la composabilité des commandes qui s’utilisent comme des verbes, sujets, quantificateurs, objets, etc que l’on peut agglutiner comme des legos pour faire des phrases. C’est mal exprimé ici, le problème n’est pas qu’on ne peut pas piloter un IDE au clavier, c’est plutôt que les IDE ne sont pas modaux et donc qu’on se retrouve avec des modificateurs de partout et des raccourcis qui ne sont pas composables. Exemple tout bête, j’ai ouvert au pif la carte de référence de IntelliJ. Pour supprimer la ligne courante, c’est Ctrl + Y. Soit. Pour supprimer le mot courant, j’ai pas trouvé mais j’imagine qu’il y a une commande quelque part qui est Ctrl + <Lettre>. Pour supprimer 3 lignes, je sais pas comment on fait, et pour supprimer jusqu’à la fin du bloc courant, non plus. Bon ok, on voit bien le problème : les raccourcis d’une interface comme ça ne se combinent pas. Sous Vim, d est le verbe pour supprimer, et ensuite tu mets le déplacement que tu veux pour supprimer un mot, une ligne, un bloc, la prochaine occurrence de foo… Si au lieu de supprimer on veut simplement copier, on utilise le verbe y mais le déplacement reste le même.

On peut limiter la casse si on active un plugin Vim qui va émuler les verbes et déplacements les plus basiques, mais on se retrouve vite coincé lorsqu’on déborde du cadre qui est émulé parce qu’on perd à nouveau la composabilité pour retomber sur des raccourcis à trois touches qui n’ont rien à voir les uns avec les autres.

Bref, les problèmes qui sont pointés se résument effectivement comme tu le dis au fait qu’un IDE qui n’est pas Vim ne se comporte pas comme Vim. Ce n’est pas un problème intrinsèque de l’IDE, mais c’est un contre-argument à la suggestion éculée d’utiliser un IDE avec un plugin Vim plutôt qu’utiliser directement Vim dans un terminal parce que ce serait "dépassé". Comme dit @pyoroalb, non merci.

J’ai envisagé de me mettre à NeoVim, pour 2024. Peut-être que c’est l’outil qui permet d’avoir le meilleur des deux mondes : véritable expérience Vim, mais avec des intégrations modernes (LSP) et un support de la souris ergonomique et totalement optionnel qui ne compromet pas l’expérience clavier pur.

J’ai longtemps été sceptique de NeoVim avant de m’y mettre il y a un an après un n-ième problème de copier-coller depuis le clipboard système qui a foiré dans Vim. Outre le fait que l’interaction avec le clipboard est transparente avec NeoVim, il y a plusieurs choses qui font que je ne regrette absolument pas Vim.

Déjà, utiliser Lua plutôt que VimScript pour la configuration est une bouffée d’air frais (ce qui en dit plus sur la qualité de VimScript que celle de Lua).

Par ailleurs, une raison pour laquelle j’était réticent à passer à NeoVim est que Vim est disponible de partout. Mais en pratique, je me retrouve souvent avec une version de Vim dépassée, et les gestionnaires de plugins sous Vim ne sont pas terrible. Une autre bonne surprise avec NeoVim est le fait que le projet distribue des binaires variés donc ce n’est absolument pas un problème pour l’installer dans mon home sur des clusters variés. Les gestionnaires de paquets sont aussi de bien meilleure qualité donc avoir ma config qui me suit de partout est un vrai confort que je n’avais qu’à moitié sous Vim.

@adri1 merci pour ces précisions, jusqu’ici je n’avais eu comme argument que « les interfaces sont faites pour la souris, c’est lent/nul », sans plus de précision ni explications (autre que « donc ça ne me convient pas », ce qui est légitime, ou des « exemples » complètement pétés) et je n’avais pas inféré cet usage du clavier depuis vim.

Merci pour le retour d’expérience, ça me conforte dans l’idée de m’y mettre sérieusement.

Pour ma part, quasi forcé à utiliser vi vers 94, découvre vim 4–5 ans plus tard. Et depuis je suis un inconditionnel de gvim (vim dans sa fenêtre graphique à lui, ce qui permet d’avoir un meilleur support des couleurs et surtout du clavier sans avoir à galérer à comprendre comment configurer tel ou tel terminal).

J’utilise souris, touches curseurs (avec ou sans CTRL et SHIFT), et une bonne partie de tout le reste — à part les macros, je n’ai jamais pu.

Mon utilisation c’est principalement pour le développement (C++, Python et vimscript), et un peu pour analyser des fichiers de logs ou tout autre chose. Donc je ne suis pas un prédicateur du minimalisme (parce que "on ne sait jamais sur quelle machine du parc on va l’utiliser") mais au contraire un gros mainteneur et utilisateur de plugins non triviaux. (et qui se recompile régulièrement vim depuis les sources)

Les forces de Vim, c’est pour moi:

• la modalité avant tout
• et la composabilité (extensible accessoirement: on peut rajouter nos propres verbes et mouvements) décrite par Adr1. Le simple fait de pouvoir penser en langage naturel (certes anglais) nos actions change la vie.
• :substitute, :global (/:v) -> en gros sed et grep directement intégrés dans l’outil.

Est-ce que je recommande Vim pour les nouveaux & nouvelles venues? Non. Pour beaucoup, l’IDE est un machin superficiellement maîtrisé, où la découvrabilité à la souris suffit; et en plus il est changé tous les quatre matins dès qu’il y a un nouveau venu un peu hype. Vim demande un investissement important avant qu’on y soit vraiment à l’aise, et que l’on y soit efficace.

PS: je ne suis passé ni à neovim et son lua, ni au vimscript v2. Je reste au vieux vimscript (et ses faiblesses) qui a l’avantage d’être portable entre les diverses moutures. Au pire pour des trucs très tordus, je suis passé par Python (j’interface les bindings pythons de libclang pour extraire des infos sur le code C++ sous le curseur pour générer le squelette de la doxygen, le corps d’une fonction à partir de sa signature, ou encore redéfinir une fonction virtuelle du parent…). Oui, on peut faire des trucs compliqués avec Vim.

note d’édition : suppression du message.

Salut,

Pour ma part j’ai utilisé vim longtemps, tant par effet de mode que par utilité véritable lorsque je développais sur certains projets.

Et puis alors que je changeais de machine régulièrement et que je ne sauvegardais pas ma configuration suffisamment, j’ai commencé à perdre plus de temps à configurer mon système qu’à réellement en tirer parti.

Ensuite j’ai dû m’attaquer à des projets plus ambitieux sur des outils et des technologies que je n’avais jamais appréhendés auparavant et j’ai opté pour la facilité.

Aujourd’hui j’aimerais savoir s’il y a des devéloppeurs qui :

• font du développement Android sur vim ;
• font du développement iOS sur vim ;
• font du développement .NET sur vim ;
• font partager le fruit de ce développement à des utilisateurs non-avertis (pour ne pas dire Mme Michu) ;
• bonus : réussissent à vivre des fruits de ce développement.

Si quelqu’un remplit ces cinq cases, je veux bien faire une interview de cette personne.

Si @SpaceFox (avec qui je constate être davantage en désaccord que l’inverse) a mentionné IntelliJ, ce n’est pas pour rien. C’est un IDE. Il est conçu par des professionnels du métier pour des professionnels du métier. Être développeur d’applications, ce n’est pas la même chose qu’être développeur système, noyau Linux ou backend. Les enjeux ne sont tout simplement pas les mêmes et je pense qu’il faut éviter de se fermer à un seul outil.

Maintenant, pour répondre au PO :

• J’utilise VSCode pour tout ce qui est développement frontend / backend.
• J’utilise Android Studio (qui est basé sur IntelliJ, me semble-t-il) pour développer sur Android ;
• J’utilise XCode pour développer sur iOS.

Ça paraît bête, dit comme ça, mais j’ai une flemme monumentale de me programmer un seul environnement de développement qui fasse absolument tout. Le jour où j’ai envie de bosser sur Qt, je ne veux pas avoir à me taper quatre heures de configuration hasardeuse qui me mèneront à utiliser Visual Studio (et non Visual Studio Code) sur son lit de CMake. Non, je prendrai Qt Creator et j’irai à l’essentiel.

De la part d’un Windowsien qui a un sous-système Debian sous WSL 2 et qui se retrousse les manches quand il doit bosser sur Mac.

Je fais parti de ceux qui se jette sur le "nouvel IDE un peu hype", comme je l’ai écrit dans ma réponse sur le forum. Mais je ne trouve pas que ce soit une raison de ne pas recommander vim.
D’une part parce qu’il peut avoir d’autre intérêt que la productivité, notamment le côté minimaliste dont tu parlais, c’est un éditeur présent sur énormément de machines et il ne fait que ce que tu lui demandes de faire (moi j’aime ces aspects).
D’autre part parce que le PDE (Personalized Development Environment) est une autre philosophie, une autre façon d’aborder son environnement de travail, et que ça relève de la préférence. Bien sûr que ça demande plus d’investissement, mais je pense que ça peut tout à fait convenir à un nouveau venu autant qu’à un barbu.
Par conséquent, pour ma part, je recommande NeoVim, même si je ne passe pas mon temps dessus, et ne suis pas un power-user.

Puisque le sujet reste centré sur vim - je pense notamment parce que à part lui (et ses dérivés) et VS Code, il n’y a pas vraiment d’éditeur qui peuvent prétendre à s’entendre à un PDE et donc il faudrait parler de leurs spécialités pour les aborder - je propose de partager nos configurations.

La mienne est, je pense plutôt simple, et se trouve ici

Quelques préférences d’affichage, un gestionnaire de paquet, des utilitaires de navigation et je délègue toute la gestion des langages à mason qui va chercher les paquets contenant les serveurs de langages.

Je développe ce que je sous-entendais. Je reconnais ce cas d’utilisation minimaliste pour travailler sur des machines distantes, faire de l’administration. Je crois l’avoir lu, nano peut tout autant faire l’affaire.

Si c’est pour développer, Vim en superficiel… il faut le vouloir. Par superficiel j’entends sans se mettre à apprendre les actions+mouvements, sans compiler depuis Vim. Juste parce que "c’est là, et j’aime à appartenir à une élite qui utilise un environnement modal", ça me parait léger vu la courbe d’apprentissage pas amicale de l’outil.

Tu peux rajouter emacs à la liste.

Ma config est tout sauf simple — derrière le lien, beaucoup de plugins pour vim. (tous les lh-*, et ceux avec vim dans le nom). Presque 30 ans d’accumulation d’ajustements. Une description que j’avais donnée sur quora il y a quelques années. Essentiellement centrée autour du dev en C++. Entre temps, j’ai commencé à faire évoluer lh-cpp et lh-clang pour mieux analyser le code courant et proposer de la génération de code ajustée. Et j’ai fait un peu plus de Python…

Pardon j’aurais pas dû faire une liste, je sais que j’en laisse sûrement de côté, j’avais pas pour but d’être exhaustif. Il y a aussi probablement SublimeText que je connais pas vraiment et peut être même l’éditeur de JetBrains car je ne comprends pas s’il n’y a que des moutures spécialisées ou si on peut trouver l’éditeur de base (IntelliJ IDEA ?) et construire son environnement par plugin.

Ce que je voulais exprimer, c’est qu’il va être difficile de parler d’IDE plus spécialisé en réponse à ce billet, parce qu’on sait qu’ils répondent à un besoin très particulier, alors que le billet parle plutôt d’un outil qui s’adapte à nos besoins.
Je n’ai pas l’impression qu’il soit pertinent ici de répondre que j’utilise l’éditeur de Godot pour faire du Godot, ou MPLab (même si pour le coup j’ai préféré éditer mes fichiers avec vim, l’éditeur était nul xD reste que j’ai utilisé le gestionnaire de projet, le compilateur, le téléchargeur, le débuggeur etc…) pour programmer les microcontroleur microchip … parce que beaucoup trop spécifique ! Eh bien j’ai un peu le même sentiment quand je parle de QtCreator ou Zerobrane Studio. Je les adore et les utilise avec plaisir, et ils traitent de techno un peu plus généralistes, mais on me bouge de projet/techno, pas sûr que je les touche à nouveau.

Bonsoir,

Je n’utilise pas du tout vim, et je n’ai pas l’intention de l’utiliser.

Alors certes, mon cas est un peu spécial. Je n’utilise jamais la souris, et je ne peux pas utiliser la grande majorité des logiciels habituels.

J’utilise eclipse au boulot quand tous les autres utilisent IntelliJ (qui n’est pas très accessible), mais à la maison quand je code pour mon plaisir, j’utilise des éditeurs ultra-légers type notepad++, et j’ai même développé ma propre solution, très utile quand ils font des grosses mises à jour de l’interface en cassant l’accessibilité (c’est malheureusement courant).

J’ai quand même comme point commun avec vous que j’ai horreur des clicodromes, des trucs lourds ou pas très réactifs du genre VSCode (pourquoi je le place lui au sommet du pire ? parce qu’un moteur web entier pour ça…)

Vu que vim est en environnement ligne de commande, je pourrais tout à fait l’utiliser, notamment sous linux via SSH. En SSH perso j’utilise nano, bien que je n’aie toujours pas compris le pourquoi du comment de leurs raccourcis totalement illogiques (genre enregistrer = Ctrl+O, quand c’est Ctrl+S partout ailleurs et quand Ctrl+O s’utilise pour ouvrir), mais bon, on finit par s’y faire.

Ce que je n’arrive pas à comprendre avec vim, c’est comment on peut trouver pratique le fait de devoir mentaliser les commandes: compter le nombre de caractères, mots, lignes, par exemple. Je veux supprimer des lignes, j’appuie un certain nombre de fois sur Shift+Haut puis ensuite Del, je m’en fous de savoir combien ! J’arrête quand j’arrive au bon endroit. Avec vim il faut d’abord compter, alors hum… 1, 2, 3, 4, 5 lignes… d5l.

Ca me parait extrêmement lent comme mode de fonctionnement, mais j’imagine que c’est uniquement une question d’habitude. Vous avez été habitué très tôt avec vim, c’est donc normal que vous soyez efficaces avec et que vous ne changeriez pour rien au monde. Tout comme moi je suis à l’aise avec mon propre mode de fonctionnement et que moi non plus, je n’ai pas envie de changer.

Petite question, des d’études prouvent que les va-et-vient entre la souris et le clavier font perdre énormément de temps. Est-ce qu’il y a quelque chose qui démontrent que la technique un peu à part de vim le rend objectivement plus efficace ? OU bien c’est uniquement une question d’habitude, et donc vouloir trancher n’a pas trop d’intérêt ?

a- Honnêtement? Je ne compte pas, et utilise au mieux les formes en d2t( (tout effacer jusqu’à la 2e parenthèse exclue — delete 2x till (). Les nombres de lignes, au mieux un 2dd pour en effacer 2, voire 3. Jamais plus. Et si je me plante, undo (u), et je recommence.

Des fois au juger je balance un 10L (low) pour me placer à la 10e ligne en partant du bas. 1 fois sur 12 je tombe juste (comme le 12 donné à l’instant). Et s’il reste un ajustement, 2 fois sur la touche du curseur et hop. ni vu ni connu.

Si tu penses en nombres de mots, lignes ou caractères, tu as tout faux. Oui, c’est possible. Mais non on ne le fait pas. Par contre, je vois quelle est ma cible, un caractère ou un autre. Et mon déplacement sera till (exclus) ou forward (inclus). Mieux, on va exploiter les text-objects: mot (w), paragraphe (p), chaine ("), bloc de parenthèse ((), accolades, quotes, tag (html), paramètre, bloc de code python, etc, etc. En mode inner (délimiteur exclu) ou a (compris). Et on balance le verbe dessus.

Et dans le doute, je me positionne en mode visuel, et fait grosso-modo comme avec les autres outils pour sélectionner ce qui m’intéresse avant de balancer l’action que je réalise dessus — et on n’est clairement pas limités à effacer, copier, remplacer.

BTW, il existe un plugin populaire, easymotion, pour aider à visualiser interactivement quels déplacements sont possibles depuis la position courante. (jamais utilisé)

b- J’ai beaucoup et longtemps râlé après la modalité au début. Et puis, arrive un moment où elle fait défaut ailleurs. Et que l’on n’a plus envie de s’en passer.

c- Pas sûr qu’il y ait une démonstration/une étude. Pour les manipulations de texte, franchement, quand on a appris le vocabulaire et que l’on commence à avoir le nez, c’est vraiment pratique.

Après, on arrive vite à des débats stériles AMA: car on passe plus de temps à se relire qu’à éditer je trouve.

Ma conclusion est de se choisir un outil et d’apprendre à s’en servir.

Ce que je n’arrive pas à comprendre avec vim, c’est comment on peut trouver pratique le fait de devoir mentaliser les commandes: compter le nombre de caractères, mots, lignes, par exemple. Je veux supprimer des lignes, j’appuie un certain nombre de fois sur Shift+Haut puis ensuite Del, je m’en fous de savoir combien ! J’arrête quand j’arrive au bon endroit. Avec vim il faut d’abord compter, alors hum… 1, 2, 3, 4, 5 lignes… d5l.

J’interviens juste sur ce point. J’avais mis en place l’option relative number qui affiche en mode normal la numérotation des lignes relativement à la ligne courante (donc 1, 2, 3, … avant et après la ligne courante), ça évite d’avoir à compter. La numérotation des lignes est normale en mode insertion.

Désormais, j’ai toujours cette option, mais je m’en sers vraiment presque plus. Le support du langage avec LSP fait que je m’en sers rarement.

Pour le reste, je fonctionne effectivement comme @lmghs. Impossible de fonctionner en nombre de mots. Je passe en mode visuel, je sélectionne la zone que je veux avec les déplacements (éventuellement je corrige un peu), puis j’agis dessus.

C’est vraiment une question d’habitude. On se sent plus à l’aise quand on maîtrise l’outil, je te rejoins totalement sur ce point.
Franchement niveau vitesse: Quelqu’un gagnerait plus à apprendre la dactylographie (et s’assurer de taper correctement avec ses 10 doigts, bépo aussi éventuellement ?) que d’utiliser Vim.-

Ce que je n’arrive pas à comprendre avec vim, c’est comment on peut trouver pratique le fait de devoir mentaliser les commandes: compter le nombre de caractères, mots, lignes, par exemple. Je veux supprimer des lignes, j’appuie un certain nombre de fois sur Shift+Haut puis ensuite Del, je m’en fous de savoir combien ! J’arrête quand j’arrive au bon endroit. Avec vim il faut d’abord compter, alors hum… 1, 2, 3, 4, 5 lignes… d5l.

Avec un affichage des numéros de lignes relatif plutôt qu’absolu, ça aide ! Même si Vim offre bien-sûr de quoi manipuler directement des objets multilignes plus complexes, ça peut quand même être utile. Je pense par exemple à des suppressions de lignes CSV ou logs, ou des champs sur un même niveau d’un JSON à rallonge, c’est les cas que j’ai à gérer en général.

Je trouve que c’est plutôt rare de devoir compter quoi que ce soit, sinon.

Nano est dans la ligné de PiCo (inclus dans PINE et avec une licence non libre) dont il reprend les raccourcis. Lire par exemple la bonne synthèse de Thomas Taylor sur how.wtf (en anglais.)

Les raccourcis sont très logiques :

• Ctrl+O est pour « write Out » (tu remarqueras qu’il n’y a de lettre « S » nulle part) ;
• tu lis (ouvrir est le contraire de fermer, et encore il faudrait que ça fasse sens) avec Ctrl+R pour « Read file » (idem, « O » nulle part)

« Mentaliser » les commandes, c’est vouloir faire Ctrl+S pour signifier « write out (to file) » Ici, il n’y a rien à mentaliser ; tu appuies sur la touche « d » qui est le premier caractère de la commande « delete » (la vraie difficulté, pour les non-anglophones, est que les commandes sont des mots en anglais …conformément aux origines de programme.)

On n’est pas non plus constamment en train de « compter le nombre de caractères, mots, lignes, » Quand tu veux supprimer deux mots ou lignes ou phrases, tu sais que tu veux supprimer deux mots ou lignes ou phrases ; tu ne te dis pas je vais aller compter d’abord… Si tu ne le sais pas, il y a pléthore de façons d’y arriver, le tout est que ce soit fait assez naturellement.
Imagine qu’on fasse de la revue ensemble. Quand je vais te demander de « supprimer les deux mots précédent » la position du curseur, je vais littéralement le formuler ainsi …et non pas en « fait shift gauche » (et là vraiment compter pour te dire combien de fois, ou alors qu’on entre dans un feedback compliqué pour que je te dise où/quand t’arrêter) puis « et supprime » Inversement, si c’est moi qui tient le clavier et que tu formules la demande de modification, tu vas la faire instinctivement façon vi… et non la façon que tu trouves pourtant plus simple.

Comme je l’ai écrit je ne sais plus où il n’y a pas longtemps, on discute littéralement (et de façon simple) avec son éditeur.

Je n’ai rien à apporter de nouveau à ce qui a été dit. Simplement, j’ai profité d’avoir un mac à mon nouveau poste essayer des outils différents de ce que j’utilise d’ordinaire et pour ne pas idiotement me fermer à ce qui se fait autour.

J’ai tenu une semaine avant de finalement renoncer, et prendre les 10 minutes nécessaires à me faire une conf neovim dans laquelle je suis efficace. Bilan de l’opération, je ne mourrai pas idiot, mais je resterai sous Vim, et discuter du pourquoi du comment de ce choix me semble une perte de temps pure et simple.

Salut, De mon côté j’utilise VS Code de façon générale, même si je n’en suis pas entièrement satisfait (on n’est jamais vraiment satisfait des outils, mais on fait au mieux en fonction des contraintes), et professionnellement Visual Studio pour du C++ compilé avec MSVC (parce que leurs outils de debug sont quand même très très bien intégrés).

Dans un terminal (serveur distant, galère locale, git bash, …) je suis bien plus à l’aise avec Vim qu’avec autre chose. Je trouve ça rassurant et efficace. J’aime bien le concept ; mais je trouve ça trop austère (et un peu dur mentalement) pour un autre cadre que les moments où je travaille dans un terminal.

J’ai longtemps été aficionado de Code::Blocks (plein de raisons : multiplateforme, LÉGER, IDE bien intégré, très personnalisable et extensible) ; mais son manque de versatilité en matière de langages et sa faible présence en entreprise ont réduit son usage au fur et à mesure que je me suis attelé à des projets de plus en plus complexes (quand ton programme agrège des modules en C++, en python, en PHP, en JS, du front, du back, du SQL, etc. j’en passe et des meilleures, un IDE monolingue c’est pas pratique).

Ce que j’apprécie chez VSC c’est qu’il a un niveau d’intégration que je juge entre correct et très bon quelque soit la technologie. Et une expérience excellente quand on mixe de multiples technologies (par exemple des technos de cloud, des dockers, plein de langages différents…).

J’aime beaucoup travailler au clavier, je suis très frustré quand je ne peux pas rester au clavier ; surtout pour me balader dans les interfaces graphiques. Par ailleurs Windows a longtemps eu ma préférence parce que je trouvais (paradoxalement!) sa GUI bien plus facile et stable à manier au clavier que les distributions linux. Et dans le même temps, je veux pouvoir utiliser une souris parce que dans une interface graphique bien intégrée, repérer l’élément qui nous intéresse c’est VISUEL, et on veut pouvoir le manipuler visuellement.

Actuellement, parce que je m’inquiète de la dégradation de l’état de mes articulations (la tendinite n’est jamais loin, et nos yeux prennent cher dans ce métier ) ; je m’essaie à Cursorless, qui permet de coder à la voix. Je trouve ça très bien pensé (bien qu’en anglais, ce qui est bien plus dur à l’oral qu’à l’écrit…), puisque ça reprend la logique de Vim d’avoir une grammaire extensible avec des actions, des cibles, des compléments qui sortent de la navigation parfois fastidieuse au clavier ou aléatoire à la souris.

Malheureusement c’est loin d’être facile à installer… un comble pour un outil d’accessibilité