Dans Emacs, tout ressemble à un service

 (yummymelon.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Emacs, plutôt qu’un système d’exploitation à part entière, orchestre des applications et des utilitaires au-dessus du noyau, et devient le client de divers services en s’appuyant sur le système de fichiers, le réseau et des programmes externes
  • Les couches UI, communication et stockage local nécessaires à un client peuvent être construites avec des bibliothèques intégrées comme le minibuffer, les buffers, URL, TCP/UDP, JSON et SQLite
  • Emacs Lisp (Elisp), un langage dynamique, permet de combiner à l’exécution des fonctions Elisp et des commandes shell afin d’orchestrer avec souplesse les capacités accessibles à Emacs
  • L’exemple de commande wttr reçoit un lieu en entrée, envoie une requête HTTP à wttr.in, extrait de JSON la région, la température et la météo, les affiche dans le minibuffer puis les enregistre aussi dans le kill ring
  • Le fichier complet wttr.el fait 67 lignes selon cloc, et l’on peut créer un client Elisp encore plus court en confiant les requêtes réseau et le traitement JSON à des outils en ligne de commande comme Python, faisant ainsi de la commande shell elle-même un service

Emacs orchestre des services au-dessus du système d’exploitation

  • Dire qu’Emacs est un système d’exploitation n’est pas exact, mais la comparaison vient de sa capacité à orchestrer des applications et des utilitaires au-dessus du noyau du système d’exploitation
  • Il peut accéder avec ses fonctions intégrées à des services du système d’exploitation comme le système de fichiers et le réseau, et exécuter d’autres programmes, ce qui facilite la composition à la volée d’un comportement de client dans Emacs
  • Comme de nombreuses tâches informatiques peuvent être prises en charge via différents modes clients, l’idée qu’un utilisateur « vit uniquement dans Emacs » tient aussi la route

Le modèle client-serveur vu à travers les requêtes et les réponses

  • Le modèle client-serveur est un schéma d’interaction où un service qui fournit des ressources et un client qui les demande se partagent le travail
    • Le client envoie une requête
    • Le serveur traite la requête puis renvoie une réponse
  • Une transaction faite de requête et de réponse peut passer par le réseau ou être exécutée localement au sein d’un même système
  • Le modèle réseau a été largement développé dans le cadre de l’architecture logicielle de style REST

Les trois zones qui composent un client Emacs

  • Un client classique prend en charge les trois zones suivantes
    • UI : gère l’entrée et la sortie utilisateur selon les besoins
    • Frontière client (Client Edge) : communique avec le service ; dans un client réseau, c’est le sous-système réseau qui joue ce rôle
    • Base de données locale : représente les données échangées ou synchronisées avec le serveur, avec une gestion qui varie selon les exigences d’implémentation

  • Composition de l’interface utilisateur

  • Communication avec le service et transformation des données

    • Pour la frontière client connectée au service, on peut s’appuyer sur les fonctions suivantes
    • La sérialisation et la désérialisation utilisent des parseurs intégrés

  • Gestion des données locales

    • Pour la représentation locale des données serveur, on peut utiliser des collections Elisp
    • Si un stockage local persistant est nécessaire, on peut utiliser SQLite
    • La complexité d’un client réel dépend des besoins et, s’il existe déjà des utilitaires en ligne de commande pour les traitements lourds, ils peuvent être reconfigurés comme des services accessibles via le shell

Comment Elisp combine les fonctionnalités

  • Toutes les bibliothèques ci-dessus sont accessibles depuis Emacs Lisp (Elisp)
  • Elisp est un langage de programmation dynamique qui autorise une composition improvisée de haut niveau à l’exécution
  • Des fonctions Elisp jusqu’aux commandes shell, il permet de combiner les comportements dont Emacs peut se servir pour orchestrer des flux complexes

Implémentation d’un client météo wttr.in

  • wttr.in est un service web de prévisions météo orienté console, qui prend en charge la sortie JSON
  • La commande wttr pour Emacs fonctionne dans l’ordre suivant
    1. demander un lieu à l’utilisateur
    2. générer l’URL de requête vers wttr.in
    3. envoyer la requête HTTP
    4. traiter la réponse JSON
    5. afficher le résultat dans le minibuffer et l’enregistrer dans le kill ring
    6. si une erreur survient pendant le traitement, afficher un message d’erreur dans le minibuffer

  • Construire l’URL de requête

    • wttr--request-url utilise https://wttr.in comme URL de base
    • Il remplace les espaces du lieu saisi par + et construit une requête sous la forme /<location>?0&format=j1
    • L’URL finale est ensuite transmise à la fonction de récupération du JSON

  • Requête HTTP et parsing JSON

    • fetch-json-as-hash-table récupère l’URL de manière synchrone avec url-retrieve-synchronously
    • Si aucune donnée n’est récupérée, il déclenche l’erreur Failed to fetch data from <URL>
    • Dans le buffer de réponse, il se déplace après les en-têtes de métadonnées HTTP, puis convertit le contenu restant en hash-table Elisp avec json-parse-buffer
    • Une fois le traitement terminé, il supprime toujours le buffer réseau téléchargé afin d’éviter les fuites mémoire

  • Assemblage du message météo

    • wttr--report-message extrait les valeurs suivantes des données JSON
      • le nom du lieu le plus proche
      • la région
      • le pays
      • la température actuelle en Celsius temp_C
      • la température actuelle en Fahrenheit temp_F
      • la description météo weatherDesc
    • Il relie les éléments de localisation non vides par des virgules et produit un résultat au format lieu : Celsius, Fahrenheit description météo
    • L’implémentation complète est disponible dans le code source de wttr.el

Utiliser aussi les outils en ligne de commande comme services

  • L’API Emacs fournit un niveau d’abstraction élevé et wttr.el, qui implémente directement la requête HTTP et le traitement JSON, ne fait que 67 lignes selon cloc
  • Une alternative plus simple consiste à confier la requête réseau réelle et le traitement JSON à un script Python nommé weather
    • la commande Elisp weather demande un lieu à l’utilisateur
    • elle compose une commande shell weather en y ajoutant le lieu comme argument
    • elle exécute la commande avec shell-command-to-string
    • elle enregistre le résultat renvoyé dans le kill ring et l’affiche dans le minibuffer
  • Dans cette configuration, la commande shell devient le service qui reçoit la requête, et la fonction Elisp joue le rôle de client
  • Grâce au caractère dynamique d’Elisp, il est possible de combiner selon les besoins bibliothèques Elisp et utilitaires en ligne de commande ; c’est cette capacité d’intégration qui permet de traiter, dans Emacs, tout comme un service

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Hacker News

  • C’est seulement parce que la lignée des Lisp Machines n’est pas devenue dominante qu’Emacs donne l’impression d’être un système d’exploitation
    « Symbolics Lisp Machine demo »
    https://www.youtube.com/watch?v=o4-YnLpLgtk
    « Emacs and Lisp »
    https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
    Lucid a forké Emacs en XEmacs pour tenter de mettre en œuvre l’une des premières idées du LSP, et la plupart des fonctionnalités de l’époque ont depuis été réintégrées dans Emacs
    https://dreamsongs.com/Cadillac.html
    « Lucid Energize Demo »
    https://www.youtube.com/watch?v=pQQTScuApWk

    • Un système d’exploitation est une machine virtuelle conçue pour être partagée par plusieurs programmes. En général, il expose l’essentiel de l’architecture du jeu d’instructions (ISA) sur laquelle il s’exécute, même s’il existe des exceptions comme Inferno, Taos ou AS/400
    • Même si les machines LISP avaient réussi, l’éditeur qui tourne dessus ne deviendrait pas pour autant le système d’exploitation. Si l’on confond plateforme et système d’exploitation, on peut alors qualifier de système d’exploitation un navigateur web ou même Roblox

  • Si l’on définit client, server et request de manière suffisamment large, on peut faire entrer n’importe quoi dans une architecture client/serveur. C’est un peu comme quand on s’efforçait de soutenir qu’Emacs suivait la philosophie Unix simplement parce qu’une fonction LISP fait bien une seule chose
    La plupart des gens peuvent admettre qu’Emacs reprend les idées des machines LISP et qu’on peut y implémenter à peu près tout ce qu’on veut. Il s’intègre très bien avec les outils CLI, mais il n’est pas clair ce qu’on gagne à appeler cela du client/serveur
    Il a absorbé des fonctionnalités au fil de plusieurs modes sur des décennies, et il contient même en interne le moteur d’analyse sémantique CEDET, aujourd’hui presque plus utilisé. Puis le LSP est arrivé, et maintenant c’est l’ère des agents, mais Emacs fonctionne aussi plutôt bien comme frontend pour agents

    • Emacs est un réfugié du LISP qui s’est replié dans le monde Unix. Il suit la philosophie LISP, pas la philosophie Unix, mais s’intègre bien à Unix
    • Autrefois, il était courant que la plupart des IDE aient leur propre moteur d’analyse sémantique. Si je me souviens bien, le premier serveur de langage Java a lui aussi été extrait du moteur d’analyse sémantique Java d’Eclipse

  • J’utilise Emacs depuis plus de 25 ans, mais dans l’entreprise où j’ai changé l’an dernier, on ne me laisse pas l’utiliser, même pour des tâches auxquelles Emacs est particulièrement bien adapté. La raison invoquée est que toute l’équipe doit utiliser les mêmes outils, et je n’ai pas réussi à convertir les autres à Emacs
    Je me retrouve donc à utiliser, de manière bien plus inefficace, des outils à usage unique séparés selon les tâches, tout en devant sans cesse apprendre de nouvelles UI et de nouveaux mappings de touches

    • À mesure que l’entreprise a grandi, elle a commencé à contrôler les logiciels installés, apparemment via Microsoft Intune pour autoriser ou bloquer les installations. Je repousse même les mises à jour ou le remplacement de mon portable, de peur de ne plus pouvoir utiliser Emacs
      Les responsables diront qu’il faut utiliser Visual Studio Code sur tous les nouveaux projets, mais le modèle de consommation utilisé n’est même pas pris en charge par VSCode. Tant qu’on respecte Git et les procédures de déploiement, chacun devrait pouvoir choisir l’éditeur avec lequel il travaille le mieux, mais j’imagine qu’on me répondrait que c’est risqué parce que c’est de l’open source non pris en charge par Microsoft et un logiciel non validé par l’entreprise
      Emacs est mon outil central au quotidien, donc s’il était interdit, j’envisagerais de démissionner. Les responsables n’essaient ni de comprendre ni de raisonner logiquement ; ils se contentent de suivre les directives d’un autre service IT
    • Dirait-on aussi qu’il est raisonnable d’imposer telnet à toute l’équipe en interdisant ssh ? Ce qui importe, c’est de ne pas demander l’autorisation d’utiliser Emacs, mais de simplement l’utiliser
      Si l’entreprise a imposé un éditeur de texte généraliste, il vaut la peine de vérifier si lancer Notepad pose aussi problème, ou si elle a même imposé un outil personnel de gestion des tâches. Il suffit de trouver une catégorie d’usage qu’Emacs peut couvrir mais pour laquelle l’entreprise n’a pas encore imposé d’outil, et de l’installer pour cet usage
    • C’est le même raisonnement que de dire que, comme gérer des personnalités différentes implique de traiter chaque personne différemment et que c’est inefficace, on a donc pratiqué une lobotomie frontale sur toute l’équipe
    • Si d’autres outils offraient autant de liberté et de possibilités de personnalisation qu’Emacs, les utilisateurs d’Emacs n’essaieraient probablement pas d’y faire entrer toutes leurs tâches. Ce n’est pas qu’Emacs soit intrinsèquement supérieur ; c’est plutôt que les autres outils sont plus limités et moins bien autodocumentés
    • Je me demande pourquoi l’affirmation selon laquelle toute l’équipe doit utiliser les mêmes outils serait valable

  • Emacs est une plateforme, et un système d’exploitation n’est lui aussi qu’une plateforme parmi d’autres. Une plateforme est une couche logicielle conçue pour permettre de construire de nouvelles choses au-dessus, donc la bonne question est de savoir si telle plateforme X convient à ce qu’on veut construire, Y
    Pour moi, X est souvent Emacs, mais cela peut aussi être Racket ou Rust. Un outil qui est à la fois une application et une bonne plateforme mérite davantage d’investissement d’apprentissage qu’une simple application

  • Le moment où j’ai assez utilisé Emacs pour comprendre « Emacs est un système d’exploitation » comme une idée crédible, et non comme une blague, a marqué un tournant important dans ma carrière

    • Il existait déjà des systèmes d’exploitation et on pouvait déjà programmer, donc je doute qu’Emacs ait réellement apporté une capacité nouvelle. Emacs est un éditeur de texte, pas un IDE ni un environnement général d’exécution pour l’automatisation ; j’ai du mal à suivre l’idée qu’ajouter Lisp à MSPaint en ferait soudain un outil extraordinaire

  • J’ai commencé à utiliser Emacs il y a quelques années pour essayer org mode, et c’est sa flexibilité extrême qui m’a fait rester

    • J’ai utilisé Spacemacs pendant un temps, mais maintenant que j’ai un Keychron G6 Pro dont je peux reprogrammer la touche Caps Lock, je pense enfin configurer moi-même init.el sérieusement

  • Emacs ressemble davantage à un environnement de programmation avec un éditeur de texte intégré. Si on le compare à certaines images Smalltalk, cela en fait un outil assez fascinant

  • Emacs n’est pas un système d’exploitation mais se rapproche davantage d’un shell, même si la notion même de shell n’est pas largement comprise

    • Si l’on voit le shell comme un moyen d’utiliser d’autres outils, alors vi est en réalité plus proche d’un shell. Il doit déléguer beaucoup de fonctionnalités à d’autres programmes Unix standard via :.!
      Emacs, en revanche, inclut toutes sortes de fonctions dans une unique distribution géante, un peu comme un système d’exploitation

  • J’ai récemment trouvé une courte vidéo d’introduction qui me semble bien adaptée pour montrer Emacs à quelqu’un qui ne l’utilise pas
    https://www.youtube.com/watch?v=mJZDmO5yOxE

    • Le init.el d’Anon Emoose m’intrigue vraiment

  • Emacs lui-même peut être exécuté en client et serveur. On lance le serveur avec emacs --daemon, puis on s’y connecte avec emacsclient ; toutes les instances, terminal et GUI, utilisent alors le même serveur et partagent les fichiers ouverts ainsi que les buffers
    Malheureusement, cela ne fonctionnait qu’en local, et j’ai essayé sans succès de rediriger le socket du serveur Emacs via ssh pour me connecter depuis un client distant

    • Avec le recul, le nom emacsclient n’était pas très bon. Quelqu’un qui découvrirait Emacs pour la première fois en 2026 pourrait facilement s’attendre à ce que, comme un client REST, il synchronise l’état d’exécution du client et du serveur via le réseau
      Ici, client et serveur désignent en fait une structure où le client envoie de simples commandes de contrôle via un domaine local Unix, c’est-à-dire un socket du système de fichiers. La prise en charge des sockets réseau est arrivée ensuite, mais ce que le client envoie reste malgré tout de simples commandes de contrôle
    • La redirection de socket ne fonctionne pas, mais si vous utilisez X11, ssh -X permet d’afficher les frames d’un Emacs distant sur votre serveur X local. Attention toutefois : avec un build GTK non PGTK, fermer une nouvelle frame peut faire planter l’Emacs distant
    • Je me demande si la cause de l’échec de la redirection de socket a été identifiée