Attends: j’ai fait un minimum d’interventions dans l’autre fil, et j’ai ouvert un fil sur emacs pour ne pas polluer l’autre quand je me suis senti le besoin d’ouvrir la guerre. Si ce n’est pas du respect, ça !
Sinon, ce que je disais dans je ne sais plus lequel des deux fils, c’est que ed (donc vi mais aussi emacs) est complémentaire de diff (man diff, regardes -e) dans la manipulation des patchs. Je crois que c’est toi qui parlait de la déclinaison sed de ed, aussi.
Là ou je veux en venir, c’est qu’aussi bien ed que vi et emacs ne sont fondamentalement que des filtres traitant des flux bien avant d’être des éditeurs, et que c’est ça qui justifie l’existence d’ed plus que sa fonction d’editeur. J’ajouterais, même si vim a dû glisser aussi vers ça qu’emacs est, au coeur, conçu sur l’idée non pas qu’il est un editeur dans lequel un operateur fait des manipulations de texte, mais un lecteur multiflux (interactifs ou non), dont un flux particulier (stdin, mais qui peut être redirigé) sert de canal de commande au filtre multiflux. C’est ce dont j’avais parlé une fois à fran mais qui etait un peu trop flou comme usage d’emacs dans ma mêmoire, c’est qu’on peut utiliser emacs en mode non interactif, et le transformer en filtre automatique temps réel de n’importe quoi trés évolué, en lui fournissant sur son entrée standard des séquences de controle effectuant des operations sur les flux qui passent dans les buffers (emacs n’a pas besoin qu’un fichier ait une taille, et sait traiter un pipe). stdout peut alors ne jouer qu’un rôle secondaire d’affichage, mais il peut aussi servir de canal de log.
Emacs est une vraie machine de turing: on peut tout faire avec.