Quels sont vos outils de développement préférés ?

• Dans la catégorie éditeurs, Helix, Emacs, Neovim, Sublime Text, Zed et les IDE JetBrains reviennent sans cesse, avec des compromis propres à chacun clairement mis en évidence
• Côté gestion de versions, la montée de jujutsu(jj) comme remplaçant du CLI git est particulièrement marquante, avec de nombreux outils GUI d’appoint comme Magit, lazygit et Sublime Merge également cités
• Pour le shell, le terminal et la gestion d’environnement, Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin et fzf forment la pile centrale
• Le message clé qui revient souvent est : « choisir des outils avec de bons réglages par défaut pour éviter une configuration sans fin » et « avec l’âge, on s’adapte davantage à de bons réglages par défaut qu’on n’essaie de plier l’outil à soi » (avec aussi des avis contraires)

---

Contexte de la discussion

• Sur Lobsters, un fil posait la question « quels sont les outils préférés des développeurs ? », avec l’idée qu’« il est difficile pour des développeurs, souvent très tranchés, de n’en citer qu’un seul »
• Plus de 130 commentaires ont été publiés en 19 heures
• Philosophie récurrente : « en vieillissant, on ajuste davantage ses préférences à des outils aux bons réglages par défaut que l’inverse », ce qui permet de rester sur « le chemin le mieux testé » et donc de rencontrer moins de bugs
  • Avis opposé : « en vieillissant, on tolère de moins en moins les mauvais réglages par défaut. Si je ne peux pas rendre un outil utilisable en quelques minutes, je passe à autre chose »

Éditeurs de texte / IDE

• Helix

  • « le bon équilibre entre personnalisation et excellente expérience par défaut »
  • Utilisé avec jujutsu, il faut recharger manuellement les fichiers ouverts après avoir changé de commit — solution temporaire : un raccourci vers :reload-all
  • Une PR de surveillance des fichiers (#14544) est en cours côté mainteneur
  • Beaucoup finissent aussi par revenir à vim faute de s’adapter au modèle selection-first
  • Fork prenant partiellement en charge les raccourcis vim : evil-helix

• Emacs

  • De nombreux utilisateurs ont simplement répondu « Emacs »
  • Magit a reçu assez d’éloges pour être cité à part
  • Évolution typique par domaine : Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired

• Neovim

  • « J’ai mis à la retraite mon .vimrc utilisé depuis plus de 10 ans et migré complètement vers Neovim »
  • Tendance autour des distributions de plugins :
    • LazyVim : la plus aboutie, avec recommandation de désactiver les raccourcis de flash.nvim
    • AstroNvim : alternative plus légère
    • Kickstart.nvim : point de départ simple pour une personnalisation maison
    • MiniMax : configuration de départ créée par l’équipe mini.nvim

• IDE JetBrains

  • Le débogueur de PyCharm est vivement recommandé — il fonctionne même dans un REPL Django, prend en charge les templates HTML/CSS/JS et permet de faire du cherry-pick par hunk
  • Si vous utilisez au moins deux produits JetBrains, la licence All Products revient moins cher

• Sublime Text / Zed

  • « Sublime Text est sous-estimé », avec des réponses indiquant un usage quotidien depuis plus de 20 ans
  • Même en codant ailleurs, ses performances rapides et ses buffers non sauvegardés persistants justifient un usage quotidien
  • Avec l’alourdissement de VSCode, certains tentent une migration vers Zed

• Kate / Notepad++

  • Kate côté Linux et Notepad++ côté Windows ont aussi été cités en réponse courte

Gestion de versions

• jujutsu (jj) — l’outil le plus souvent cité cette année

  • « Je ne pensais pas abandonner le CLI git, et pourtant c’est arrivé »
  • « Il est rare qu’un outil soit à la fois plus simple et plus puissant ; jujutsu réussit les deux »
  • Les utilisateurs disent que rebase et commit amend deviennent agréables
  • Inconvénient : les réglages par défaut manquent de finition, notamment couleurs et templates — le rendu par défaut est décrit comme un « vomi de licorne arc-en-ciel à fort contraste »

• Outils complémentaires pour Git

  • tig : « une meilleure version de git log », utile pour le staging interactif
  • Magit : incontournable pour les utilisateurs d’Emacs
  • Sublime Merge : « une couche GUI pour git, mais extrêmement bien faite », intégrable aussi avec jj via merge-editor = "smerge"
  • lazygit : encourage à tenter des opérations complexes comme rebase, revert, stash ou la gestion de multiples remotes
  • delta : utilisé comme pager git, fournit des diff avec coloration syntaxique ; combiné à lazygit, permet de basculer entre affichage côte à côte et inline
  • difftastic : diff basé sur la syntaxe et non sur les lignes
  • git revise : « devrait faire partie de git par défaut »
  • Beyond Compare : outil de diff / merge / synchronisation de dossiers utilisé depuis 20 ans

Shell / terminal

• Fish

  • « Il fait tout ce que bash et zsh font, avec une excellente expérience sans configuration particulière »
  • On peut toujours exécuter des scripts bash si nécessaire
  • Il est décrit comme un outil où l’on découvre régulièrement de nouveaux raccourcis utiles (par ex. alt+<left|right> pour l’historique des répertoires)

• Émulateurs de terminal

  • WezTerm : copier/coller uniquement au clavier (ctrl+shift+space), duplication d’onglet sur le même système avec ctrl+shift+t, client SSH et multiplexeur intégrés
  • Ghostty : intégration native macOS — popover de dictionnaire avec Cmd+Ctrl+D, glisser-déposer, onglets natifs, excellente qualité de rendu des polices
  • kitty : « l’exemple type d’un bon outil dont les réglages par défaut fonctionnent simplement, tout en laissant beaucoup de place à la configuration »

• tmux

  • La première commande exécutée à l’ouverture d’une session terminal
  • Pratique contre les déconnexions SSH ou les fermetures accidentelles de terminal — et permet de conserver le même mode de travail entre Mac et NixOS

• Starship

  • Peut s’intégrer à n’importe quel shell, mais souffre de lenteurs sur les grosses repositories lors des commandes git status / branch

Gestion d’environnement / dépendances

• Nix / NixOS

  • « C’est peut-être un syndrome de Stockholm, mais après ça on n’arrive plus à utiliser d’autres distributions Linux ni d’autres systèmes de build »
  • Les nix shell par projet permettent de minimiser les paquets système et de figer exactement les versions sans polluer le PATH global
  • « Un haut niveau de confiance dans le fait que cela fonctionnera pareil dans 1 an, ou dans 5 ans »
  • « Une fois la courbe d’apprentissage passée, c’est magique. La configuration d’un OS aurait toujours dû ressembler à ça »

• mise

  • Gestionnaire de versions d’outils qui remplace direnv, avec intégration possible même dans une CI légère
  • « une alternative strictement meilleure à asdf »
  • La découverte de mise activate permet parfois de supprimer complètement direnv
  • Avec mise watch et le système de tâches, on peut définir des actions par projet et exécuter des tâches sur changement de fichiers

• Dev Containers

  • Leur principal avantage est de partager l’environnement de déploiement docker/container et l’environnement de développement
  • Inconvénient : l’outillage reste immature (même la CLI de référence n’a pas de commande stop)

• chezmoi

  • Permet de garder un environnement de développement cohérent entre machines pro et perso, en gérant aussi alias git, configuration Neovim, tokens d’accès et installation d’autres outils

Débogage / profilage

• rr — débogueur record/replay

  • « L’outil principal pour déboguer en C/C++ : une fois enregistré, on peut rejouer de façon déterministe à l’infini »
  • Permet de poser un watch sur une adresse mémoire puis de remonter jusqu’à la dernière écriture
  • « temporal debugging bisection » — avec des watchpoints, on peut naviguer avant/après l’apparition d’une corruption mémoire

• Pernosco

  • Débogueur de time-travel + analyse de flux de données
  • A joué un rôle décisif pour le focus handling des processus de contenu multiples de Firefox et pour des travaux de compatibilité Chrome autour de about:blank

• RenderDoc / Tracy / RemedyBG

  • RenderDoc : outil à tout faire du débogage graphique, supérieur sur les fonctions de base au débogueur Metal de XCode
  • Tracy : « si l’on construisait un profiler avec des ressources illimitées, on obtiendrait Tracy »
  • RemedyBG : débogueur apprécié pour son confort d’utilisation

• XCode Instruments

  • En profilage 3D/GPU shader, fournit des annotations du coût d’exécution ligne par ligne
  • Permet d’analyser les causes de stall — attente de fetch mémoire, attente de synchronisation, divergence de flot de contrôle
  • « L’avantage d’un écosystème qui contrôle à la fois le matériel, les drivers, le langage de shading Metal et l’outillage »

• Autres

  • strace, extrace, perf — trio indispensable pour le débogage
  • gdb — encore fréquemment cité en réponse courte

Recherche / traitement de texte

• fzf : intégration à la recherche inverse de l’historique shell, avec un « niveau de flou juste comme il faut »
  • Le motif rg '' | fzf permet de rechercher dans tout le texte d’un repo, puis de renvoyer immédiatement dans le prompt shell un vim foo.rs +123 au moment de choisir un résultat
• ripgrep : « le bon comportement dès la sortie de boîte, je n’ai même jamais essayé de le configurer »
• septum : recherche de code interactive — par exemple « trouver en 7 lignes ou moins les occurrences contenant triangle, vertex et mesh, mais excluant physics »
• fastmod / spacemod : remplacements massifs
• autojump : permet d’aller vers un ancien répertoire de travail avec j whatevs grâce à un fuzzy match sur l’historique
• zoxide : proche d’autojump, avec une navigation plus fluide
• awk : toujours puissant pour « extraire un petit peu puis retoucher un petit peu »
• entr : « surveille ces fichiers et exécute ça » — bien adapté au lancement automatique des tests sur une base de code

JSON / données / outils de transformation

• jq : standard de fait pour traiter le JSON, avec recommandation de lire le manuel jusqu’au bout, ainsi que la jq track d’Exercism
  • gojq : messages d’erreur bien meilleurs que jq natif, avec prise en charge du YAML en entrée, ce qui permet de conserver les mêmes réflexes
• fx : exploration détaillée de grosses sorties JSON
• hexdump : notamment hexdump -C, utile en débogage embarqué — motif picocom --baud 115200 /dev/ttyUSB | hexdump -C
• hexyl : visualiseur hexadécimal en couleur
• bat : alternative à cat avec coloration syntaxique
• choose, fd : remplaçants respectifs de cut et find

Historique shell / presse-papiers / notes

• Atuin : synchronisation de l’historique shell, recherche selon le contexte du répertoire et du repo git
• CopyQ : gestionnaire de presse-papiers d’environ 2000 éléments, utile pour retrouver un travail passé lorsqu’une note a été oubliée
• histprune : personnalisation du Ctrl+R de fzf — suppression immédiate d’une entrée d’historique avec alt+D
• Obsidian : migration depuis Logseq, avec intérêt pour le Markdown pur qui facilite la collaboration avec des LLM/agents
• Joplin : AGPLv3, applications desktop, mobile et web, backend WebDAV/OneDrive/S3, stockage direct sous forme de fichiers .md

Build / automatisation des tâches

• just : remplaçant de make — centré sur les tâches plutôt que sur le build, avec une interface cohérente du type just lint quel que soit le langage
  • « permet d’alterner, cible par cible, entre le mode ligne par ligne de make et un mode script complet shell/python/node »
  • Inconvénients : les scripts embarqués sont écrits dans $TMPDIR avant exécution, et l’outil utilise son propre langage de templates, au rendu un peu uncanny valley
• Task (go-task) : alternative en YAML, plus batteries-included
• universal-test-runner : détecte automatiquement la manière de lancer les tests dans un repo puis les exécute, avec transmission d’arguments supplémentaires
• chezmoi : gère de façon cohérente dotfiles et installation d’outils entre machines

HTTP / réseau / secrets

• Hurl : « oubliez les applis HTTP GUI qui cherchent à collecter des informations » — format texte simple pour écrire des requêtes curl, bien adapté aux tests d’intégration
• curl : cité très souvent en réponse courte
• SOPS : chiffrement de secrets avec des clés age/SSH, usage du type sops exec-env secrets.yaml -- some command
• Mutagen : synchronisation de fichiers bidirectionnelle en temps réel au-dessus de SSH — utile pour travailler sur des machines distantes
• forge : remplaçant du CLI GitHub, avec prise en charge de Codeberg, plus rapide et plus propre

Divers / workflow

• Quarto : présentations rapides en markdown
• Nushell : shell influencé par PowerShell, permettant d’écrire de façon fiable de gros scripts de transformation comme GeoPackage → PostGIS ou vue PostGIS → PMTiles. Inconvénient : avant la 1.0, les mises à jour cassent souvent des choses
• Typst : cité comme remplaçant de LaTeX, avec préférence pour une syntaxe call-by-value
• Topiary : formateur multilingue
• Hunk : visionneuse de diff terminal review-first pour les agentic coders, souvent affichée à côté d’un agent de code en mode --watch
• Raycast / Alfred : lanceurs macOS, avec snippets, presse-papiers et recherche web paramétrable
• Ergodox EZ : clavier utilisé depuis 10 ans, apprécié à la fois pour sa personnalisation et sa consommation électrique
• Joplin / Fossil : auto-hébergement de notes et de wiki
• AeroSpace / Sway : gestionnaires de fenêtres en mosaïque

Messages récurrents de fond

• « choisir des outils avec de bons réglages par défaut pour éviter une configuration sans fin » — Helix, Fish, ripgrep et mise sont cités comme exemples représentatifs de cette philosophie
• Point de vue opposé : certains ont aussi fini, à force d’ajustements infinis, par construire leur propre système d’outils — « maintenant, je n’y touche que quelques fois par an »
• Effet collatéral de l’ère des agents IA : perception croissante que jq, Markdown et les outils de texte structuré favorisent la collaboration avec les LLM — Markdown pur d’Obsidian, mode watch de hunk, recommandation d’apprendre le manuel de jq relèvent du même mouvement
• Avantage de macOS en débogage graphique : le profilage GPU de XCode Instruments est jugé écrasant face à Linux et Windows
• Renaissance du CLI vs typographie : alors même que les outils terminal se multiplient, on observe aussi que les longues sorties de LLM/agents restent souvent plus agréables à lire dans un navigateur ou une application dédiée grâce à une meilleure typographie

[kirinonakar]

J’en ai essayé quelques-uns, mais aucun ne m’a vraiment convenu, donc je suis en train de le créer moi-même. Je m’inspire de notepad++, VS Code, Zed et Obsidian, et je ne reprends que les fonctionnalités dont j’ai besoin.

[xguru]

J’utilise beaucoup en ce moment un trio composé de cmux, tmux et mux.
Quand je me connecte en SSH via cmux à un serveur relié avec Tailscale, il m’affiche avec fzf les sessions tmux existantes regroupées, puis je choisis celle dans laquelle entrer.
Une fois dedans, je bascule sur mux.

cmux - Terminal pour macOS basé sur Ghostty pour les agents de codage IA
Show GN: mux – gestionnaire de sessions tmux qui transforme les sessions de codage IA en aperçu live

[edunga1]

Sur Mac, pour saisir du coréen dans le terminal, il ne faut pas appuyer deux fois sur Entrée ? (deux fois au total, une fois après avoir terminé la composition du coréen, puis une autre pour valider la saisie)
Le seul qui n’avait pas ce problème, c’était wezterm, donc j’ai fini par passer dessus.

[onixboox]

J’aime bien zed

[snisty]

Je suis devenu incapable de vivre sans Claude Code maintenant. + tmux..
Et pour ajouter, VSCode comme éditeur de texte..
Sinon, un IDE indispensable comme Visual Studio pour les builds, à peu près.

[hwhang0917]

fzf, jq, rg, awk ❤️

[jjpark78]

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,

[GN⁺]

Avis de Lobste.rs

• J’utilise Helix comme éditeur de texte. Pour moi, l’équilibre entre personnalisation et excellente expérience par défaut est parfait.
  Pour la même raison, j’utilise Fish comme shell de terminal. L’expérience de base est excellente et il y a très peu de réglages à faire pour l’utiliser comme je le souhaite.
  En vieillissant, j’apprécie davantage d’adapter mes goûts à des outils avec de bonnes valeurs par défaut assumées, plutôt que de passer mon temps à peaufiner la configuration.
  Atuin est excellent pour synchroniser l’historique du shell entre machines distantes et pour la recherche contextuelle dans l’historique selon le répertoire courant ou le dépôt git. Il a d’autres fonctions, mais je n’utilise que celles-là.
  Mise me plaît aussi à plusieurs niveaux, mais surtout comme gestionnaire de versions d’outils. Il a remplacé direnv que j’utilisais auparavant, et je commence aussi à l’intégrer peu à peu dans de légers workflows de CI pour mes projets personnels.

  • Suivre le chemin des bonnes valeurs par défaut, c’est aussi suivre le chemin le plus testé, donc on rencontre moins de bugs. En général, c’est un choix judicieux.
  • Il n’y a pas que « adapter ses goûts aux valeurs par défaut » et « passer son temps à tout configurer ». Dans mon expérience très personnelle, j’ai configuré, configuré, configuré encore, jusqu’à arriver exactement où je voulais, et maintenant je n’y touche presque plus.
    Quelques fois par an tout au plus. Mon Emacs est devenu une sorte de boîte à outils Studley personnelle.
  • J’ai envie d’aimer Helix. C’est un projet vraiment élégant et ses valeurs par défaut sont séduisantes, mais j’ai beaucoup trop de mémoire musculaire Vim accumulée.
    En revanche, j’ai complètement adopté Neovim il y a quelques mois et mis à la retraite mon .vimrc qui avait poussé organiquement pendant plus de dix ans. Ça m’a rendu un peu triste, mais je jalouse moins Helix maintenant.
    Mise est très bien aussi et ne demande pratiquement aucune configuration. J’ai commencé à utiliser Fish il y a quelques mois également, et à part quelques fonctions utilisateur, je le laisse presque entièrement par défaut.
    Ripgrep aussi fait « naturellement ce qu’il faut » dans son état de base, au point que je ne sais même pas si j’ai déjà essayé de le configurer.
  • Comment faut-il s’y prendre pour vraiment apprendre à utiliser Helix ? J’essaie de quitter Neovim parce que sa structure avec des plugins qui tirent plus de 50 dépôts me fait trop craindre les attaques de la supply chain.
  • Je me reconnais vraiment dans ça. En vieillissant, j’ai de plus en plus de mal à comprendre les gens qui passent autant de temps à bricoler leurs outils et leurs logiciels. Ce n’est pas amusant, et ça n’en vaut pas la peine.

• Emacs

• C’est peut-être un syndrome de Stockholm, mais c’est Nix. Ce n’est pas parfait, mais une fois que Nix m’a permis de travailler de façon plus expressive et plus efficace, il a pratiquement ruiné les autres distributions Linux et les systèmes de méta-build pour moi.
  Et en bonus, pwntools est aussi un outil agréable à utiliser en dehors des CTF. Par exemple, c’est très pratique pour manipuler des sockets au niveau du bit depuis un REPL Python.

  • J’aime à la fois Nix et pwntools. En tant que joueur de CTF moi aussi, je suis curieux : si tu as un environnement de pwn CTF basé sur Nix, j’aimerais savoir comment tu l’as monté.
    Jusqu’ici, je lançais toujours une nouvelle VM Ubuntu sous libvirt, j’y installais les outils et je travaillais dedans ; tu aurais une approche basée sur Nix à recommander ?

• Emacs, évidemment, et en particulier Magit

• Nix. Il y a une courbe d’apprentissage. J’ai passé plusieurs années à côtoyer des utilisateurs ou évangélistes de Nix avant de m’y mettre sérieusement, mais au final c’est vraiment très bien.
  En travaillant sur plusieurs projets, j’en avais assez que chaque type de dépendance système soit géré par un outil différent. Un pour les versions de Node, un pour les versions de Python, etc.
  J’en avais aussi assez des échecs de build difficiles à déboguer à cause d’incompatibilités entre projets. Le genre de situation où $foo casse dans le projet A, je le mets à jour via Homebrew, et maintenant c’est le projet B où $foo casse.
  C’est aussi pénible quand le processus de build dépend de nombreuses dépendances installées sur le système, souvent cachées, et que le build échoue « pour une raison obscure ».
  J’ai déplacé autant que possible tout cela vers des nix shells par projet. Je garde les paquets système au strict minimum, et dans chaque projet je fixe précisément les versions des outils nécessaires : dépendances, runtimes, compilateurs, etc.
  Ça ne pollue ni le PATH global ni les autres projets. Si ça fonctionne chez moi aujourd’hui, j’ai une assez grande confiance dans le fait que ça fonctionnera encore dans un an ou dans cinq ans.
  Quand je veux mettre à niveau un outil, je peux aussi le faire sans craindre d’affecter les autres projets, et s’il y a une régression je peux facilement revenir en arrière ou ne figer qu’une dépendance précise sur une ancienne version.
  C’est encore mieux quand les collègues travaillent aussi sur des projets utilisant Nix. Le temps supplémentaire nécessaire pour configurer et maintenir le nix shell est mutualisé, et on a bien plus confiance dans le fait que tout le monde dispose du même environnement de développement.

  • Pour des raisons similaires, je me suis récemment beaucoup intéressé aux Dev Containers. Je trouve l’idée très bonne, mais malheureusement la qualité des outils ne suit pas encore.
    Par exemple, même la CLI de référence n’a toujours pas implémenté la commande stop. Malgré tout, si on utilise Docker ou des conteneurs pour le déploiement, il y a l’avantage de pouvoir partager beaucoup de configuration entre environnement de développement et environnement de déploiement.
    https://containers.dev/
    https://github.com/devcontainers/cli

• rr(https://rr-project.org/) est un logiciel magiquement bon, au point que je ne pourrais plus m’en passer.

  • C’est le genre d’outil dont j’aurais eu besoin tous les jours autrefois. Belle découverte. Je pense le mettre dans mon second cerveau pour pouvoir le retrouver la prochaine fois que j’en aurai besoin.
  • Par curiosité, à quel endroit rr t’apporte-t-il le plus de valeur ? Je comprends l’idée générale présentée sur la page d’accueil du projet.
    Le concept d’enregistrer un échec une seule fois, puis de le déboguer de façon déterministe autant de fois qu’on veut, semble évidemment utile.
    Mais si je demande un retour d’expérience concret, c’est parce que je n’ai pas encore eu ce déclic du type : « waouh, ce bug / workflow précis aurait été impossible à résoudre sans rr ».

• Je viens d’un background d’administrateur système, donc je suis beaucoup plus du côté « bonnes valeurs par défaut avec un minimum de configuration ». Pourtant, deux choses récentes m’ont fait sortir de cette habitude.
  On en a beaucoup parlé sur ce site aussi, mais jujutsu(jj) est franchement un vrai plaisir à utiliser. Je ne pensais pas abandonner la CLI git, et pourtant c’est arrivé.
  J’ai évité pendant des années d’apprendre à utiliser et configurer nvim, mais nvchad m’a permis de m’y mettre. Le nom est affreux, mais pour moi c’est une excellente configuration de départ, juste ce qu’il faut d’opinionnée sans cesser d’être minimaliste.
  Bien sûr, maintenant j’utilise directement ma propre configuration minimale à partir de zéro.
  À part ça, comme j’utilise pas mal Python, je dois aussi dire que les outils astral restent régulièrement agréables à utiliser. J’espère qu’Anthropic en prendra bien soin.

  • jujutsu, c’est doublement vrai. D’abord, le changement lui-même est agréable, puis les valeurs par défaut de jj ne sont pas encore totalement polies, donc on finit par y retoucher une deuxième fois.
    À moins d’aimer le texte façon vomi de licorne arc-en-ciel ultra contrasté sur fond sombre, il y a pas mal de travail à faire sur les couleurs et les templates.

• En fait, c’est Emacs. Je déplace peu à peu mes tâches informatiques vers Emacs et je commence à adopter ses valeurs par défaut.
  Emacs est vraiment facile à personnaliser, et beaucoup de raccourcis clavier font ce qu’il faut dans tous les modes.
  La liste de ce vers quoi je migre lentement est : Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired.
  Quarto est aussi très bien pour créer rapidement des présentations en Markdown. J’utilise Nix et nix-darwin pour tous mes dotfiles.

  • Pour l’usage de dired, ça vaut le coup de jeter un œil à Dirvish.

• Emacs. Je ne l’utilise pas souvent, mais écrire des parseurs avec ragel est un plaisir.

• Sublime Text est clairement sous-estimé par beaucoup trop de gens.

  • J’aurais aimé aimer Sublime Text, mais son mode vi ne correspondait pas assez à la mémoire musculaire que j’avais acquise avec Vim, donc je n’ai pas réussi à m’y installer.
    Je crois que ça s’appelait quelque chose comme « vintage ». Aujourd’hui, dans le genre de situation où j’aurais voulu aimer Sublime Text, j’utilise plutôt Zed.