Depuis que j’utilise un éditeur de texte pour RI, j’utilise ESS. Cela fait maintenant 10 ans. Et donc, j’ai décidé que c’était suffisant.

J’ai commencé à utiliser R pendant mes études de master pour mes analyses statistiques. Je voulais apprendre le cœur de la langue et j’ai donc décidé que je ne voulais pas avoir d’interface entre moi et la langue. J’écrivais tout mon code directement dans la console, enregistrais quelques Rdata et gardais une trace de l’historique. Et j’ai beaucoup appris.

Quelques années plus tard, j’ai commencé mon doctorat et j’ai décidé que c’était trop archaïque. Pour une raison quelconque, je voulais m’éloigner de Rstudio et j’ai commencé à chercher un bon éditeur de texte pour R. J’ai été surpris de constater qu’il existe de nombreuses bonnes options. Mais j’avais un plan : j’ai décidé d’en essayer quelques-unes pour voir ce que je ressens avec chacune d’elles, puis de choisir. J’en ai fait une liste de 3 ou 4 et j’ai commencé par le premier. C’était Emacs avec ESS. Je n’ai jamais réussi à atteindre le 2ème.

Dès le début, Emacs m’a semblé très naturel et intuitif. Je suppose que sa structure et sa façon de travailler correspondent à mon état d’esprit. J’ai adopté ESS de la même manière, simplement dans le cadre de mon expérience Emacs. J’ai appris les raccourcis clavier de base, la connexion à la console R et quelques raccourcis pour le développement de packages et les tracés. En un rien de temps, j’ai eu un excellent environnement de travail pour R. C’était la phase de tomber amoureux et j’ai tout simplement adoré tout cela.

ESS a un objectif intéressant : rendre les statistiques faciles et possibles avec Emacs. Si l’on y réfléchit au-delà du cadre de R, la tâche est énorme. ESS fournit de nombreuses fonctionnalités pour d’autres langages statistiques, tels que SAS, S-plus et récemment même Julia. Selon Wikipédia, « il a la capacité de soumettre un travail par lots pour des packages statistiques tels que SAS, BUGS ou JAGS lorsqu’une session interactive n’est pas souhaitée en raison du temps potentiellement long requis pour accomplir la tâche ». Il pourrait éventuellement s’agir de l’un des tout premiers éditeurs pour R, bien avant même que Rstudio ne soit imaginé.

Son retard descend jusqu’en 1992 avec la version 3.41. Cela pourrait être autour de la version 18 d’Emacs. Au moment de la rédaction de cet article, ESS est à la version 25.01.0 et Emacs à la version 30.2. Il est évident que ESS a été conçu avec des outils Emacs très anciens et limités. Et pour l’utilisateur expérimenté, il est également clair qu’ESS a du mal à s’adapter à l’évolution d’Emacs. L’équipe de développeurs derrière Emacs a été très intelligente en incorporant des bibliothèques de grande valeur à la fois pour l’utilisateur final et pour le programmeur elisp. Emacs est si flexible et polyvalent qu’il est capable de suivre les technologies de pointe telles que le LSP, le tree sitter et, plus récemment, l’IA générative. Malheureusement, nous ne pouvons pas en dire autant de l’ESS.

L’équipe ESS a vraiment fait un travail remarquable avec ce package. Non seulement il fonctionne, mais il va au-delà et essaie de vous fournir de nombreux outils pour faciliter le travail avec les statistiques. R est la star du package, il contient 9 fichiers elisp qui lui sont dédiés exclusivement et de nombreuses fonctionnalités supplémentaires ou de support dispersées dans le code. Il fait l’objet d’une attention particulière pour l’ajout de nouvelles fonctionnalités et la résolution de bugs. J’ai toujours aimé la facilité avec laquelle démarrer une nouvelle console R et y associer n’importe quel tampon de script R. J’aime beaucoup son système de débogage. Et j’ai un tas de fonctions R enroulées autour d’un simple code elisp à exécuter sur des raccourcis clavier. Ils ont créé un excellent environnement de développement pour le code R. Malheureusement, cela est également très traditionaliste par rapport à l’ancienne méthode R, et les choses commencent à devenir floues lorsque vous essayez des méthodes alternatives pour développer du code R, telles que box et rhino.

Malgré toutes les merveilles qu’il offre, il présente également de nombreux inconvénients. La base de code est trop volumineuse et trop ancienne. Lorsque vous essayez de contribuer, ou simplement de réparer ou de modifier quelque chose qui semble simple, vous pouvez facilement vous perdre dans un labyrinthe de fonctions elisp et de variables dispersées un peu partout. Il existe cependant une certaine structure, donc une fois que vous commencez à vous y habituer et que vous savez quel script est destiné à quoi, le labyrinthe peut être parcouru à l’aide de xréfs. Mais ensuite, le code est trop vieux, il s’est enrichi pendant 40 ans. Plus d’une fois, j’ai eu des situations dans lesquelles, lors de la mise à jour vers une nouvelle version d’Emacs, de nombreux avertissements et/ou erreurs apparaissaient soudainement pour quelques paquets. C’est parce qu’Emacs a changé certaines choses dans certaines fonctions, parfois il peut s’agir de nouvelles variables, de valeurs par défaut différentes, d’un changement d’emplacement ou d’implémentation de quelque chose, etc. En général, j’attends juste que les responsables le corrigent. Il y a toujours des utilisateurs qui exécutent la version préliminaire d’Emacs la plus récente et ils le signalent rapidement afin que les responsables puissent le réparer rapidement. Malheureusement, ce n’est pas le cas de l’ESS. D’après mon expérience, ESS a toujours été le dernier à corriger des bugs comme celui-ci. Et lorsque vous plongez dans le code, il regorge de commentaires sur ce qui serait une bonne implémentation, de code commenté et de nombreuses solutions pour corriger ce type de bugs, plutôt que d’essayer de l’implémenter de la nouvelle manière suggérée par Emacs. Et je ne leur en veux pas. Leur code est si volumineux et interdépendant que parfois, réparer quelque chose qui semble simple peut interrompre d’autres fonctions en aval, ou interrompre son implémentation si nécessaire en amont.

En plus de tout ce bruit, l’ESS peut être trop opiniâtre sur certains sujets. Mon exemple préféré est celui de travailler avec des projets. Contrairement à tout autre mode majeur d’un langage de programmation, ESS a sa propre définition d’un projet. Il y a toute une discussion dans le numéro 1289 si vous voulez lire les avis. Il est prévu de définir les projets à la manière de R, mais ensuite, si vous choisissez de travailler avec Rhino vous n’avez que des maux de tête. J’avais l’habitude de travailler sur un projet R pour un pipeline Big Data qui était une base de code bien structurée, en dehors de « la voie R », donc, chaque fois que je voulais utiliser les fonctionnalités du projet, elles ne m’étaient pas disponibles. J’ai fini par ajouter un .Rprofile juste pour ça. Mais il est bouleversant que les développeurs de packages puissent décider à quoi devrait ressembler un projet R.

Tout cela nous amène à leur incapacité à mettre en œuvre une implémentation Tree Sitter pour ESS. Je garde mes commentaires à ce sujet, vous pouvez vérifier les détails vous-même dans le numéro 1239, lancé le 5 février 2023. Trois ans plus tard, tirez vos propres conclusions.

Il semble qu’ils aient tout simplement trop de pain sur la planche. Même lorsque R est leur objectif principal, il doit faire glisser tout le reste de leur base de code, ce qui est énorme. ESR est né parce que nous pensons que les utilisateurs de R méritent une meilleure expérience Emacs. Nous méritons un mode majeur où R est un citoyen de premier ordre, au même titre que python ou java script. Et cela nous permet de suivre les derniers outils R comme radian et air. L’objectif d’ESR est d’être un package minimaliste axé sur R, avec le support de tree sitter.

Il existe quelques différences remarquables avec ESS :

• Emacs Speaks R au lieu d’Emacs Speaks Statistics. ESR se concentre sur R.

• Utilisation d’un gardien d’arbre. Cela ouvre de nombreuses nouvelles possibilités pour la coloration syntaxique, la navigation dans le code et l’édition du code.

• Utilisation des fonctionnalités intégrées d’Emacs. Ne réinventez pas la roue et ne mettez pas à jour les outils Emacs les plus récents.

• Carte clé minimale. ESS fournit une énorme carte de touches qui ressemble aux boutons et menus de Rstudio. ESR tente de s’éloigner de cette stratégie en gardant la carte clé propre.

• Utilisation d’outils modernes pour alimenter le développement R, tels que Eglot et Vterm, qui peuvent prendre en charge Radian et Air.

ESR est né comme un mode tree sitter pour R, mais grâce au soutien de la communauté qui s’y intéresse, il continue de croître comme une alternative à ESS. Nous sommes grandement reconnaissants pour le travail accompli par l’ESS tout au long de ces années, et nous avons décidé de donner un nom à l’ensemble pour honorer cela. Nous travaillerons dur pour nous assurer qu’Emacs Speak R.