Y a-t-il encore des gens qui utilisent Emacs ?

• Après avoir découvert Linux en 1997, l’auteur a alterné entre Vim et Emacs, avant de passer à VSCode et IntelliJ en 2015, puis de revenir à Doom Emacs en 2022 dans l’environnement de VM Linux distante de Snowflake
• VSCode facilitait l’apprentissage et le développement grâce à une UI moderne, une taille réduite, une configuration basée sur JSON et une intégration LSP pour Go et Rust ; pour le développement Java, IntelliJ était un choix plus réaliste
• Sur les anciennes VM Linux de Snowflake, le travail consistait surtout à écrire des shell scripts et des fichiers de build Bazel, et un flux de travail basé sur SSH convenait mieux qu’un environnement graphique distant, ce qui a rendu Emacs à nouveau nécessaire
• Doom Emacs, avec ses valeurs par défaut raisonnables, son intégration des langages, ses raccourcis de style Vim, son menu contextuel basé sur space et une structure de fichiers de configuration simple, donne à Emacs une sensation proche d’un IDE
• La raison essentielle de continuer à utiliser Emacs est de pouvoir conserver le même environnement de développement partout, sur MacBook, laptop Linux, workstation cloud Linux ou serveur FreeBSD, avec seulement shell, tmux et Emacs

---

D’un IDE DOS/Windows à un éditeur Linux

• Découverte de Linux vers 1997 avec Caldera OpenLinux 1.1
• Avant cela, l’auteur utilisait surtout Borland Turbo C++ et Visual Basic, et était habitué aux IDE très aboutis de l’époque
• Deux livres d’introduction à Linux lui ont fait découvrir Vim et Emacs, tous deux présentés comme des options avancées
• Même si les IDE utilisés auparavant semblaient plus complets, il a appris les bases et suivi les tutoriels de Vim et d’Emacs
• Jusqu’aux environs de 2015, il a alterné entre Vim et Emacs
  • Emacs convenait mieux aux longues sessions de code
  • Vim excellait pour modifier rapidement plusieurs fichiers, par exemple lors de travaux sur pkgsrc

Pourquoi le passage à VSCode et IntelliJ

• Même si Vim et Emacs faisaient le travail, leur intégration des langages était limitée, ce qui a suscité un intérêt pour des éditeurs plus modernes
• Lors du passage à macOS, l’auteur a aussi essayé Atom et Brackets, mais les a trouvés fragiles et lourds à cause d’un trop grand nombre de fonctionnalités et d’options de configuration
• VSCode, apparu en 2015, a immédiatement donné l’impression d’être l’outil adapté
  • Il avait une apparence moderne et restait relativement léger
  • À l’époque, l’éditeur de configuration reposait sur des fichiers JSON, sans panneau de réglages, ce qui semblait plus facile à maîtriser
• En commençant à apprendre Go et Rust, l’intégration LSP de VSCode pour chaque langage s’est révélée très utile
  • autocomplétion du code
  • mise en évidence des erreurs en temps réel
  • accélération de l’apprentissage
• Chez Google, pour travailler sur des projets Java utilisant Bazel, IntelliJ était le choix naturel
  • Il a bien essayé de faire du développement Java avec Emacs, mais IntelliJ était excellent et constituait l’option réaliste
• Chez Microsoft, pour travailler sur une base de code C++ et des machines Windows distantes, il a continué à utiliser VSCode avec un plugin Vim
  • Beaucoup travaillaient directement sur les machines distantes via RDP
  • Il préférait lancer VSCode sur son bureau local puis se connecter en SSH à la machine distante

Ce qui a motivé le retour à Doom Emacs chez Snowflake

• Après son arrivée chez Snowflake en 2022, le développement se faisait dans une ancienne VM Linux, et le travail quotidien consistait surtout à écrire des shell scripts et des fichiers de build Bazel
• Dans cet environnement, VSCode et IntelliJ ne résolvaient pas vraiment les problèmes, et les contraintes des environnements graphiques distants l’ont poussé à revenir à un mode de travail en SSH vers une VM locale
• Il lui fallait de nouveau un éditeur adapté aux longues sessions de travail, et ce choix était Emacs
• Son ancien init.el contenait des centaines de lignes d’options accumulées au fil des ans, qu’il ne comprenait pas suffisamment ; il a donc voulu tout jeter et repartir de zéro
• C’est à ce moment-là qu’il a découvert Doom Emacs
  • Doom Emacs est une « distribution » d’Emacs préconfigurée
  • Il fournit des valeurs par défaut raisonnables
  • Il propose des intégrations de langage prédéfinies
  • Il offre une expérience familière aux anciens utilisateurs de Vim
  • Sans se revendiquer comme un IDE, il en donne concrètement la sensation à l’usage

Comment Doom Emacs a changé l’expérience d’utilisation

• Une fois Doom Emacs configuré, Emacs a de nouveau donné l’impression d’être « le bon outil », comme VSCode en 2015
• De nombreuses fonctions d’Emacs sont devenues plus faciles à découvrir grâce à des menus contextuels interactifs derrière des raccourcis basés sur space
• Cela coexiste avec des raccourcis de style Vim tout en offrant un flux de commandes moins fatigant pour les poignets
• La configuration est répartie dans trois fichiers simples
  • config.el : définit les réglages globaux comme le thème ou la police
  • init.el : permet de choisir les modules spécifiques à Doom à activer
  • packages.el : installe les paquets non inclus dans Doom
• Les valeurs par défaut sont raisonnables, et les détails susceptibles d’être ajustés sont abondamment commentés
• Grâce aux progrès du LSP et à des fonctions modernes comme tree-sitter, Emacs donne désormais l’impression d’un IDE
  • il offre une véritable intégration des langages pour la plupart de ceux que l’auteur utilise

La valeur d’un même environnement de développement partout

• La fonctionnalité la plus puissante est de pouvoir retrouver le même environnement de développement quelle que soit la machine utilisée
• Cela inclut un MacBook, un laptop Linux, une workstation cloud Linux ou encore un serveur FreeBSD personnel
• Il ne faut que shell, tmux et Emacs
• Quand on travaille sur différentes machines, retrouver le même environnement et la même mémoire musculaire a une valeur directe pour la productivité
• C’est ce besoin qui fait d’Emacs un outil encore plus important qu’autrefois

Doom Emacs en fait-il trop ?

• Certains reprochent à Doom Emacs « d’en faire trop », mais c’est précisément ce qui le rend utile en pratique
• L’auteur se demande s’il réduira un jour sa configuration afin d’en apprendre davantage sur Emacs lui-même
• Le fait que plusieurs modules tiers modernes finissent par entrer dans les paquets standard d’Emacs alimente aussi cette réflexion
• Récemment, il a eu envie d’essayer les distributions Bedrock ou Emacs Solo
• Mais l’énergie d’activation nécessaire pour changer reste élevée, et même en choisissant cette voie, il en viendrait sans doute à se redemander pourquoi ne pas aller jusqu’à Emacs « brut »

Réserve vis-à-vis d’Elisp, d’Org mode et de Magit

• Il ne comprend toujours pas complètement en quoi le fait qu’Emacs repose sur Elisp transforme autant les workflows des gens
• Il serait possible d’implémenter davantage de logique et de workflows dans Emacs, mais il fait déjà presque tout facilement avec des shell scripts
• Les scripts lui paraissent plus fidèles à l’esprit Unix, dans une perspective de type « Unix is my IDE »
• Le fait que Org mode et Magit ne soient pas des applications indépendantes mais restent attachés à Emacs ne lui plaît pas
• Tant qu’il devra continuer à travailler régulièrement sur différentes machines distantes, Emacs restera un outil important

[GN⁺]

Avis sur Lobste.rs

• J’ai écrit ce post parce que le sujet est trop drôle
  Pas à cause d’une question en particulier, mais parce que je vois des personnes très haut placées dans l’entreprise « découvrir » les outils en ligne de commande en utilisant des agents de codage en CLI, puis essayer de montrer à quel point cette nouvelle découverte est utile
  Jusqu’ici, l’exemple typique, c’est tmux, et maintenant j’attends qu’ils réalisent bientôt que Vim et Emacs existent aussi
  Ces outils existent depuis longtemps, et si vous demandez à un « développeur 10x senior » de l’entreprise, il vous dira probablement qu’il les utilise
  Et pourtant, on les a souvent traités de « haha, c’est une relique antique. Passons au web !!11 » Peut-être qu’il y avait une raison pour laquelle ces développeurs continuaient à les utiliser ;P

  • Un des bons côtés de la « bulle des productions générées de mauvaise qualité », c’est que le texte brut redevient un support valide et important
    Cela inclut le fait que la CLI devient plus courante, et qu’une grande partie du savoir transmis oralement est enfin documentée. À condition, bien sûr, qu’il s’agisse de connaissances produites par des humains
    J’espère que, même une fois cette période pénible passée, ces bons aspects resteront
  • La plupart des utilisateurs d’Emacs l’utilisent probablement en GUI. Je n’ai pas de chiffres, mais j’imagine que c’est une majorité écrasante

• Moi aussi, je fais partie de ceux qui commencent tout juste à l’apprendre
  J’avais essayé Doom Emacs il y a quelques années, mais c’était assez lent pour devenir agaçant à cause de la latence, donc j’ai laissé tomber. Je ne sais pas si c’est désormais de l’histoire ancienne grâce à la compilation native ; pour l’instant, j’utilise encore un Emacs de base sans configuration, donc c’est difficile à évaluer. J’utilise la 30.2 de Nixpkgs, et il semble que la compilation native soit activée par défaut
  Les fonctions comme écrire des e-mails dans Emacs ne m’intéressent pas particulièrement ; j’ai surtout besoin d’un éditeur que je puisse façonner comme je veux. Ce serait bien aussi qu’il puisse me servir plus tard si je veux apprendre Lisp, probablement Janet. Helix n’a toujours pas de plugins, donc côté Lisp il n’y a quasiment pas d’options. J’aime aussi la philosophie du « tout est texte », mais il reste à voir si cela me conviendra vraiment
  Il y a aussi quelque chose d’intimidant à l’apprendre en 2026. À cause de plusieurs décennies de connaissance implicite accumulée, dès qu’on lit quelque chose, on voit pleuvoir des noms de paquets, des noms de commandes, etc., et on se sent vite submergé alors qu’on veut juste faire $THING. Du coup, j’ai pris le parcours d’apprentissage guidé avec Mastering Emacs
  Les raccourcis clavier par défaut sont aussi assez bizarres. Je sais qu’on peut tous les remapper, mais ça ajoute encore du travail. En plus, j’ai fabriqué moi-même un clavier ergonomique séparé, et j’ai aussi ajusté le firmware pour un mode de travail à la Vim/Helix qui n’utilise pas les touches modificatrices au cœur du flux
  Comme je navigue entre trois types de claviers — MacBook Pro, PC et clavier custom — je dois trouver des raccourcis cohérents qui ne me fassent pas fondre le cerveau. hjkl est au même endroit sur tous les claviers, mais pas des touches comme Ctrl

  • Si les raccourcis clavier sont difficiles et que vous êtes plus à l’aise avec Vim, evil vaut le coup d’œil
    On vous fera peut-être la leçon en disant qu’evil est pour les réfugiés de Vim qui ne veulent pas apprendre le « vrai évangile d’Emacs », mais le vrai évangile d’Emacs®, c’est de l’utiliser de la manière qui vous convient le mieux
    J’utilise Emacs depuis 1998 et je n’étais pas du tout fan de Vim. Vers 2011, j’ai commencé à avoir un peu de troubles musculosquelettiques au poignet, donc j’ai essayé des paquets censés réduire ça ; j’ai beaucoup utilisé god mode pendant quelques années, mais ça restait étrange
    Puis, pour « prouver que ça ne marcherait pas », j’ai essayé evil sans avoir jamais utilisé Vim de ma vie ; en une semaine, j’étais aussi à l’aise qu’avec god mode, et un mois plus tard, j’étais plus rapide qu’avec les raccourcis Emacs officiels
    Ça ne veut pas dire pour autant que les raccourcis par défaut sont mauvais. Mes poignets ne sont pas en super état, donc votre expérience peut être différente. boon ou meow pourraient aussi très bien vous convenir
    Mais si evil vous convient, il n’y a absolument aucune raison de culpabiliser. Emacs change parfois l’utilisateur, mais bien plus souvent encore, Emacs change pour l’utilisateur
  • Doom dépend énormément de la manière dont on le configure. Et cet aspect continue de s’améliorer avec le temps
    Le mieux reste de le configurer soi-même, mais c’est beaucoup de travail, et des projets comme Doom facilitent clairement l’entrée des nouveaux utilisateurs
  • Le fait que les raccourcis par défaut soient bizarres est justement ce qui m’avait plu dans Doom Emacs
    Avant, je connaissais plutôt bien les raccourcis Emacs de base, mais je ne les ai jamais trouvés naturels, surtout parce qu’ils étaient peu faciles à découvrir
    Doom Emacs utilise un préfixe SPC pour presque tout, et si on s’arrête un instant, un menu contextuel temporaire apparaît pour expliquer les complétions possibles, ce qui est vraiment pratique. Ça permet de découvrir des fonctions qu’on ne connaissait pas, sans entrer en conflit avec le mode modal de Vim
    Du coup, une configuration avec le mode Vim pour l’édition de texte et les combinaisons SPC pour les actions Emacs me semble être un bon équilibre
    Les raccourcis par défaut d’Emacs ont aussi des avantages. Les raccourcis de base de manipulation de texte sont partagés avec readline, et même avec macOS. Les raccourcis de gestion de texte à la Emacs dans macOS se sont même propagés à VSCode sans entrer en conflit avec les raccourcis standards du presse-papiers, ce qui rendait VSCode sur macOS plutôt agréable
    Après être passé sur Windows et Linux, il m’a été pratiquement impossible de supporter VSCode sans plugin Vim
  • Si vous venez de Helix, meow peut aussi valoir le détour
    J’ai entendu dire qu’il fournit nativement des fonctions proches de Kakoune et Helix, avec une approche qui cherche davantage à ne pas gêner. Je ne les ai pas utilisés moi-même, donc je parle d’après ce qu’on m’a dit
    Je pense que le paquet evil qu’on m’a recommandé a le défaut de prendre trop de contrôle sur les raccourcis clavier et de mal s’intégrer avec les paquets externes, ce qui oblige à ajouter beaucoup de paquets « adaptateurs »
    meow demandait plutôt peu d’entretien une fois configuré

• Je l’utilise depuis 33 ans, et il fait tout ce que j’attends d’un éditeur ou d’un IDE

• J’ai longtemps alterné entre Doom et (n)vim, mais récemment je me suis surtout fixé sur Neovim
  Le principal problème que j’ai rencontré avec Emacs, c’est assez ironiquement que sa maintenance est pénible. Quand on met Doom à niveau, la synchro des paquets se décale souvent, au point qu’il ne reste plus que l’option nucléaire : tout réinstaller
  Bien sûr, j’aurais sans doute pu corriger ça de manière plus « avancée », mais à un certain moment on finit juste par vouloir qu’un outil fonctionne. Quand on a du travail à faire, devoir gérer une config cassée et une dépendance excessive à l’éditeur devient difficile à supporter
  Cela dit, org-mode et la navigation générale d’Emacs me manquent
  Chaque fois que j’essaie des solutions « modernes » comme VSCode ou CLion, je rencontre encore plus souvent le même genre de problèmes. Il n’y a pas de vraies fonctions d’accessibilité, donc au lieu d’une navigation purement au clavier il faut cliquer maladroitement, et le comportement « Vim » reste incomplet par rapport à l’original
  Si j’utilise Neovim aujourd’hui, c’est simplement parce que ça marche bien. En vrai, si j’avais demandé à un agent de code de corriger ma config pendant deux minutes, je pourrais probablement dire la même chose de mon Emacs actuel (:

  • J’ai essayé plusieurs fois la fonction update de Doom, mais ça tournait toujours mal
    Maintenant, chaque fois que je veux faire une mise à niveau, ou que c’est nécessaire à cause d’une mise à niveau d’Emacs, je supprime avec rm -rf ~/.emacs.d/ puis je reconfigure Doom depuis zéro. ~/.doom.d/ est versionné
    Avec ce flux, je n’ai pas eu de problème

• Je suis un drôle de personnage qui fait du développement, de l’écriture et même des e-mails avec Emacs, et ça dure depuis environ 15 ans, mais je n’ai jamais réussi à trouver le temps ou la marge mentale pour apprendre elisp
  Même quand je touche aux fichiers de configuration, je ne sais pas vraiment ce que je fais. Et pourtant, cela reste mon environnement le plus productif, ce qui montre à quel point cet éditeur est remarquable :-)
  Lire sérieusement Mastering Emacs est sur ma liste de choses à faire depuis tellement longtemps que c’en est presque embarrassant

  • Je suis presque dans le même cas. À force de corriger ma config et d’éditer, j’ai fini par absorber un peu d’elisp par osmose, mais ce que je sais réellement est si limité que c’en est un peu gênant
  • M-x high-five
    De mon côté aussi, je n’utilise que très peu de paquets et je garde les raccourcis clavier d’origine. La fonction high-five n’existe pas vraiment, mais c’est peut-être enfin l’occasion de me plonger dans elisp

• Je n’aimais pas le rendu de Vim et j’en avais assez des outils de type Electron/VSCode, donc je suis passé à Emacs il y a environ deux ans
  J’ai accroché à avy et à quelques plugins de saut, mais ce qui m’a retenu et en a fait mon outil principal pour modifier du code, encore aujourd’hui, c’est magit

• L’entreprise cliente avec laquelle je traite au travail dépend entièrement de l’exploitation d’énormes fichiers CSV, mais chez eux personne ne semble savoir comment ouvrir ou examiner des données dans des fichiers de 1 Go
  Ils ne connaissent même pas la commande head à utiliser pour demander les en-têtes CSV

• Après des années en X/GUI, je viens juste de passer à -nw
  Je n’utilise la version Pgtk que pour les présentations