From madore@news.ens.fr
Path: eleves!not-for-mail
From: madore@news.ens.fr (GroTeXdieck)
Newsgroups: ens.forum.informatique.editeurs
Subject: Emacs vs vim
Date: 8 Jun 1999 23:00:59 GMT
Lines: 206
Sender: madore@clipper.ens.fr
Message-ID: <7jk7bb$qh9$1@clipper.ens.fr>
References: <7jjbu6$fuu$1@clipper.ens.fr> <7jjfq4$ofv$1@clipper.ens.fr> <7jjg3t$6td$1@twilight.efge.org> <7jjl4d$49j$1@clipper.ens.fr> <7jjq83$bgg$1@twilight.efge.org>
NNTP-Posting-Host: clipper.ens.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: clipper.ens.fr 928882859 27177 129.199.129.1 (8 Jun 1999 23:00:59 GMT)
X-Complaints-To: forum@clipper.ens.fr
NNTP-Posting-Date: 8 Jun 1999 23:00:59 GMT
X-Newsreader: Flrn (0.4pre2 - 05/99)
X-Mark: BOG, possibly
Xref: eleves ens.forum.informatique.editeurs:76

Est-il possible de parvenir à dresser une comparaison (je n'ose pas
dire objective mais du moins pondérée) entre Emacs et vim sans tomber
dans les flamewars ?  Je vais essayer de donner quelques éléments.  À
charge à d'autres de compléter (le salpêtre et tout ce qui s'enflamme
facilement sera impitoyablement censuré).

On peut toujours commencer par un rappel d'histoire.  L'éditeur
original d'Unix s'appelle ed, et il dérive du qed de Multics ; c'est
un éditeur ligne à ligne.  Pour autant que je sache, il est aussi
vieux qu'Unix ; en tout cas, il est déjà présent dans le Unix V5 que
j'ai pu essayer (avec, cependant, certaines fonctionalités en moins
par rapport à la version actuelle, comme le fait que 1,$ ne puisse pas
s'abrévier en , (% est aussi possible dans la version GNU de ed), ou
la commande n très pratique, ou encore les regexps étendues).  En
1976, Bill Joy et Chuck Haley de l'UCB ont développé l'éditeur ex, une
version améliorée de ed, qui a été incluse avec la première
distribution de BSD en 1977.  C'est en 1978, avec 2BSD, que sont
apparus la bibliothèque termcap, et l'éditeur vi, compatible avec ex
mais plein écran, qui l'utilisait.  Alors que System III et System V
restaient avec ed comme éditeur par défaut, vi était devenu l'éditeur
standard de BSD.  Il a été intégré (avec beaucoup d'autres
berkeley-ismes) dans SVR4 en 1989.  Autrement dit, vi est un produit
100% pur Unix, et d'ailleurs Unix à la sauce californienne.

L'héritage d'Emacs est différent : il nous vient du MIT et sa culture
est celle d'ITS et des Lisp hackers.  Donc dès les origines on
comprend que ce soit un monde différent.  En un sens, Emacs est le
descendant de Teco (Text Editor and COrrector), l'éditeur d'ITS (et
plus tard de RSTS/E), développé par tous les grands noms du AI lab (je
ne sais plus qui l'a créé au juste, mais il est sûr que tout le monde
d'alors y a laissé son empreinte : c'était un peu le test of hackerdom
à l'époque de rajouter une commande à Teco) ; en tout cas Emacs
provient de la même culture (Stallman est un disciple du grand Bill
Gosper, ne l'oublions pas).  Bref, l'Emacs original est écrit pour ITS
sur PDP-10, et est basé sur le Lisp, tout autre possibilité aurait été
hérétique.  La guerre entre ITS et Unix a été perdue par ITS, c'est
bien connu, quand DEC a décidé de ne pas donner de successeur au
PDP-10 (ceux qui auraient oublié cette page de l'histoire de
l'informatique feraient mieux de relire le « Brief history of
hackerdom » d'ESR).  En septembre 1983 (à la « chute » du AI lab),
quand RMS a lancé le projet d'écrire un système d'exploitation libre,
il a décidé de le rendre compatible avec Unix et de l'appeler GNU.
Son premier souci a été de réécrire Emacs, et ça a donné GNU Emacs.
RMS ne voulait pas apprendre à utiliser ed ou vi, et il lui fallait un
éditeur.

Enfin il faut parler de vim.  Mais je ne sais pas quoi en dire
exactement.  On trouve encore des Vrais vi dans les *BSD ainsi que
dans les systèmes dérivés de SVR4 (comme Solaris).  En revanche, GNU
(i.e. Linux) a un Faux vi, vim, VI iMproved, développé par Brian
Moolenaar.

Note au passage : vim a un problème (sans parler des aspects
techniques) par rapport à vi ou à Emacs, c'est qu'il n'est pas libre.
En tout cas pas suivant les définitions de la FSF : la license de vim
précise « If you distribute a modified version of Vim, you must send
the maintainer a copy, including the source code. » alors que la
définition d'un logiciel libre suivant la FSF dit que « you should not
be required to notify anyone in particular, or in any particular
way ».  (L'Open Source Definition ne mentionne pas ce point, donc je
suppose que ça passe.)  Ceci ne s'applique pas à vi, qui est distribué
suivant la license BSD.

Il faut aussi mentionner XEmacs qui est né d'un conflit entre la FSF
et je-ne-sais-qui pour une raison qui a déjà été oubliée.  Comme j'ai
dit que je resterais modéré, je préfère ne pas parler du tout de
XEmacs parce que je ne saurais en dire que du mal (lisez un message
intitulé « CONNERIE DE MERDE DE XEMACS » dans editeurs.emacs pour
savoir pourquoi).

Personnellement, j'utilise vim pour éditer les petites choses, les
fichiers de configuration (gros ou petits) et les choses comme ça.  En
fait, j'utilise vim mais je serais aussi content d'utiliser vi pour la
même chose.  Les seules features de vim dont j'ai vraiment l'utilité
c'est le support pour les longues lignes (>255 caractères), l'undo
illimité et éventuellement le mode remplacement.  Aussi utile, il y a
le fait d'indiquer en bas de l'écran si on est en mode insertion, ou
peut-être la possibilité d'utiliser les flèches plutôt que hjkl pour
se déplacer (je ne m'en sers pas).  Mais en pratique je survis très
bien avec un vi au lieu de vim.  (D'ailleurs, à l'École, j'utilise
plutôt /bin/vi que /usr/local/util/bin/vim parce que je n'ai toujours
pas réussi à produire un fichier de config qui ne me fasse pas plein
de trucs affreux dont je ne veux pas.)  J'ai aussi commencé à utiliser
ed pour un certain nombre de choses.  Par exemple, pour faire une
recherche-remplacement globale, ça va plus vite.  Quand on a reçu un
message d'erreur de gcc qui indique un numéro de ligne, ed a
l'avantage de ne pas effacer l'écran, et faire un changement juste sur
une ligne ça se passe bien avec ed.  Par extension je m'en sers de
plus en plus.  (Il y a aussi le fait que sur hell, je ne sais pas si
c'est sur Quisar ou sur la SuSE qu'il faut taper, quand je lance vi
j'ai plein de choses qui me font peur comme du syntax-highlight, et
que par conséquent j'utilise ed comme solution de repli, parce que
personne n'a encore fumé de syntax highlight pour ed.)  J'utilise
Emacs principalement pour les programmes et pour le HTML, ainsi que
pour les textes longs (par exemple les posts dans forum ; les courts
je les tape directement dans l'éditeur intégré de flrn ou dans
l'espèce de cat> de Mail).  Bref, je n'utilise pas vi et Emacs pour
les mêmes choses et donc je ne suis pas si bien placé pour comparer.
Mais comme apparemment je suis le seul à ne pas être complètement
fanatique (i.e. polarisé sur un seul éditeur), je fais tout de même
l'effort.

Que dire d'Emacs si ce n'est qu'il est très gros.  Pour commencer, il
inclut un système Lisp complet.  Par conséquent, on peut, en théorie
du moins, tout faire avec Emacs ; en tout cas, il est Turing-complet.
C'était déjà le cas de Teco, et il est évident que RMS savait
programmer en Teco comme tout le monde au AI lab.  Bon, mais d'un
autre côté, le Lisp c'est quand même plus clair que le Teco (à
l'époque de Teco, mettre un interpréteur Lisp dans un éditeur c'était
plus un rêve, impossible faute de place, qu'un interdit, et ce n'est
pas vraiment par choix que Teco est aussi incompréhensible).
Évidemment, le choix du langage ne pouvait être *que* Lisp
(maintenant, RMS voudrait le remplacer par son dialecte Scheme) pour
des raisons culturelles.  Ça suffit à en mécontenter certains.  vi,
lui, pas plus que ed, n'est pas Turing complet.  Ce n'est ni un
avantage ni un inconvénient, c'est un fait.  Je ne sais pas ce qu'il
en est de vim.

Du coup, on a tout mis dans Emacs.  Vraiment tout.  Des jeux, des
émulateurs d'autres éditeurs (dont vi et teco), un émulateur de
terminal, un browser web (avec support CSS naturellement), un
calendrier perpétuel, un psychanalyste (M-x doctor), un générateur de
zippyism (culture Lisp-hacker oblige), et la liste continue.  Linus
Torvalds : « While Linux is larger than Emacs, at least Linux has the
excuse that it needs to be. »

vi est encore tout petit, mais il n'a pas un certain nombre de choses
qu'on peut trouver utile si on s'en sert comme éditeur pour tout,
comme le syntax-highlight.  vim a tout ça, mais il n'est plus si petit
que ça (enfin, il est quand même loin derrière Emacs), surtout avec
les divers supports X11 qui s'y sont intégrés.

En revanche, une fois que l'éditeur est lancé, question vitesse, Emacs
n'a rien à se reprocher, il est tout à fait convenable.

Autre chose, le choix des touches.  Si j'utilise hjkl dans vi, en
revanche, il m'arrive rarement d'utiliser C-b C-n C-p C-f dans Emacs.
Même si elles sont mnémotechniques (back, next, prior et forward je
suppose), ces touches sont vraiment mal choisies, surtout que le f est
à gauche du b (c'est lui qui sert à aller à droite).  Pour le home et
end, je trouve que là Emacs a mieux choisi que vi : ^ et $ c'est bien,
ça rappelle les regexps, mais manque de chance ^ est à droite de $,
alors que C-a et C-e c'est assez commode et assez proche.

On se moque souvent d'Emacs pour ses bindings fumés (Escape Meta Alt
Control Shift).  C'est vrai qu'il y en a pas mal, et le plus
regrettable c'est certaines confusions comme C-x i (insérer un
fichier) alors que C-x C-f sert à lire un fichier, donc on serait
tenté de taper C-x C-i mais ça fait un truc totalement différent.  La
touche meta, en revanche, je la trouve pratique.  Bien sûr, elle sert
aussi sous vi (M-x effacer un caractère, M-: passer en mode
commande...  en tout cas c'est comme ça que je fais) mais ils
décomposent ça en escape (quitter le mode insertion) plus commande et
du coup on ne revient pas au mode insertion quand c'est fini.

Il y a quelques choses que je reproche sérieusement à vi.  Les deux
plus sérieux, ce sont d'une part les choix bizarres qui ont été faits
sur la position du curseur (et notamment le décalage d'un caractère
entre mode normal et mode insertion, ou encore le fait que le curseur
en mode normal se positionne à la fin des tabulations et non au
début), choix qui donnent des commandes comme a versus A, o versus O
ou ainsi de suite.  Essayez de taper un petit texte (en mode
insertion) et de revenir en arrière d'un caractère avec M-h, ça fait
tout drôle.  La deuxième chose c'est la fausse logique utilisée dans
le choix des commandes.  On essaye de faire croire que c'est logique
mais en fait ce ne l'est pas.  Par exemple, 4x efface quatre
caractères comme si on tapait xxxx alors que 4yy ne fait pas l'effet
de 8y ou de yyyyyyyy.  dh efface un caractère à gauche (h), dl un
caractère à droite (l), tandis que dj et dk effacent _deux_ lignes, et
on ne sait pas pourquoi dd efface la ligne courante...  Bref, une
volonté louable de logique mais pas réussie et finalement on en
ressort plus confus qu'autre chose.

Un truc bien dans Emacs, sinon, c'est la sélection.  Le principe en
est très simple, avec un mark qui existe toujours, un point qui est le
curseur, et la sélection qui s'étend entre les deux.  C-space permet
de placer le mark, et C-x C-x d'échanger le mark et le point et c'est
tout ce qu'il faut savoir.  C-w coupe, M-w copie et C-y paste.  Dans
vi tout cela n'est pas très commode ; vim y remédie en introduisant la
commande v (mode visuel), mais je trouve quand même que le système
d'Emacs est mieux.

Là où vi torsche carrément par rapport à Emacs c'est dans tout ce qui
touche aux regexps, à la facilité (héritée de ed) de les utiliser pour
tout et n'importe quoi et notamment pour appliquer une opération à
certaines lignes.  Les regexps d'Emacs louzent, et en plus elles sont
non standard.  Les recherches-remplacement de vi sont mieux que celles
d'Emacs - en revanche la recherche incrémentale intéractive d'Emacs a
du bon.

Autre chose : vim a l'avantage d'avoir un undo avec redo ; le redo
manque cruellement à Emacs.  En fait, ce n'est pas tout à fait vrai,
on peut obtenir redo sous Emacs en tapant x C-_ C-_ mais c'est dû à la
manière fortement non-intuitive dont l'undo information est gérée.
(Sous vim quand on fait undo sur une opération puis qu'on fait des
changements l'opération est perdue ; sous Emacs ce n'est pas le cas.
Je considère ça comme un inconvénient d'Emacs plutôt qu'un avantage.)

Gros inconvénient d'Emacs : il est tellement configurable qu'on finit
toujours par tout casser sans réussir à faire ce qu'on veut.  Cela
dit, je pense que vim a aussi cet inconvénient (pas vi !) mais en
moins grave.

Bon, comme bilan temporaire, disons que vi est plus maniable au niveau
ligne (héritage ed, line-based) et qu'Emacs est plus maniable au
niveau caractère (héritage teco, character-based).

From madore@news.ens.fr
Path: eleves!not-for-mail
From: madore@news.ens.fr (GroTeXdieck)
Newsgroups: ens.forum.informatique.editeurs
Subject: Re: Emacs vs vim
Date: 9 Jun 1999 17:30:09 GMT
Lines: 104
Sender: madore@jonque.ens.fr
Message-ID: <7jm8b1$heh$1@clipper.ens.fr>
References: <7jjbu6$fuu$1@clipper.ens.fr> <7jjg3t$6td$1@twilight.efge.org> <7jjl4d$49j$1@clipper.ens.fr> <7jjq83$bgg$1@twilight.efge.org> <7jk7bb$qh9$1@clipper.ens.fr> <7jkep4$2ai$1@clipper.ens.fr>
NNTP-Posting-Host: jonque.ens.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: clipper.ens.fr 928949409 17873 129.199.129.4 (9 Jun 1999 17:30:09 GMT)
X-Complaints-To: forum@clipper.ens.fr
NNTP-Posting-Date: 9 Jun 1999 17:30:09 GMT
X-Newsreader: Flrn (0.4pre2 - 05/99)
Xref: eleves ens.forum.informatique.editeurs:99

Max in litteris (informatique.editeurs:77) scripsit :
> mais tu es vraiment bete, alors ?

Cette explication ne m'était jamais venue à l'esprit.

> - si le curseur ne bougeait pas entre le mode commande et le mode insertion,
> on n'aurait pas le feedback visuel qui permet de savoir qu'on en revenu
> en mode commande.

Mauvaise excuse, changer d'excuse.  Là, j'en ai rarement vue d'aussi
pipo.  Un truc en bas de l'écran, comme fait vim, c'est tout à fait
suffisant et même préférable.

Discutons d'un point plus précis.  On peut imaginer un curseur de deux
façons différentes : soit comme un trait imaginaire qui se positionne
entre deux caractères soit comme un carré qui recouvre un caractère.
Appelons ça le curseur-trait et le curseur-carré.  Le curseur est
presque toujours (à part dans certains systèmes graphiques, style
XEmacs ou Micro$oft Beuargh, et pour une fois il n'ont pas tort)
représenté comme un carré ; pourtant, on l'imagine presque toujours
comme un trait, correspondant au bord *gauche* du carré.  C'est pour
ça qu'on insère entre deux caractères ; et c'est pour ça que la touche
backspace et la touche delete sont à peu près symétriques : dans une
vision curseur-carré il y aurait trois opérations naturelles (effacer
le caractère sous le curseur, à gauche du curseur ou à droite du
curseur).

Je trouve que la vision curseur-trait est vraiment la meilleure.
C'est de loin la plus répandue.  Même si le curseur est représenté
comme un carré on y pense comme à un trait.  (Et même en mode
remplacement : on pense à l'opération de taper une touche comme
« insérer à gauche puis supprimer à droite » plutôt que véritablement
« remplacer puis déplacer le curseur vers la droite ».)  Cela
s'applique aux marques : quand on marque un point (dans Emacs par
exemple), on marque en fait l'intervalle entre les deux caractères qui
était au bord gauche du curseur au moment où on positionne la marque,
et quand on fait une opération jusqu'à la marque, on la fait depuis
cette marque jusqu'au bord gauche de la nouvelle position du curseur.

Ce que je reproche à vi sur ce point c'est qu'en mode commande il
confond les deux visions du curseur.  D'un côté si je positionne une
marque avec ma, que je me déplace et que j'efface tout jusqu'à la
marque avec d`a, il va effacer l'intervalle demi-ouvert (fermé à
gauche et ouvert à droite) entre les deux positions du curseur (celle
où j'ai tapé ma et celle où j'ai tapé d`a).  C'est la même chose que
fait Emacs et n'importe quel éditeur raisonable (à mon avis) et c'est
la vision curseur-trait (puisque le caractère le plus à droite de
l'intervalle n'est pas concerné par l'effacement).  En mode insertion
il est *parfaitement clair* sous vi que le curseur est un trait.  De
même, l'action de dh ou de dl en mode commande montrent bien qu'on
doit penser au curseur comme un trait (ou le fait qu'il n'existe pas
de commande pour effacer à droite du bord droit du curseur comme
devrait être le cas si on pensait au curseur comme un carré).  Mais
certains aspects du mode commande font quand même penser au curseur
comme un carré.  Par exemple le fait qu'on ne puisse pas aller, en
mode commande, au-delà du dernier caractère.  C'est le problème des
poteaux et des intervalles, et vu le nombre de positions que le
curseur de vi peut occuper en mode commande sur une ligne donnée,
manifestement on essaye de nous le montrer comme un carré ; ou
l'existence de commandes comme p (insérer à droite du bord droit du
curseur ; alors que, soit dit en passant, i insère à droite du bord
gauche donc si i correspond à P on se demande ce qui correspond à p).

Bref, confusion.  Et, non, je ne tétratomise pas.

Au niveau des lignes, il faut toujours penser au curseur comme
occupant tout l'espace entre son bord supérieur et son bord
inférieur.  C'est normal et c'est logique.  Il n'y a pas de dualité
ligne / colonne.

Donc je dis que pour logifier la chose : soit on adopte la vision
curseur-trait tout du long, et alors le curseur en mode commande doit
pouvoir aller après la fin de la ligne, la commande p ne doit pas
exister (ou alors être bien cachée), pas plus que la commande a, et le
passage en mode commande ne doit pas déplacer le curseur.  Soit on
adopte la vision curseur-carré en mode commande et curseur-trait en
mode insertion, ce qui se tient aussi, mais alors dh et dl doivent
effacer deux caractères, on invente un truc spécial pour dire « rester
à la position courante », disons \, et d\ efface le caractère _sous_
le curseur de même que dd efface la ligne _courante_ ; et ma marque la
position _sous_ le curseur, et d`a efface de la position courante
incluse à la position marquée incluse (de sorte que mad`a efface le
caractère courant) ; et on trouve un truc pour effacer à droite (du
bord droit) du curseur.

Est-ce que je me suis exprimé clairement ?

> - les combinaisons de touches que tu cites sont parfaitement logiques, c'est
> juste que tu ne veux pas entendre parler des regles qui les justifient..
> y et d, au meme titre que < ! et quelques autres, permettent de faire 
> quelque chose a un bout de texte... Le bout de texte correspond par defaut
> au deplacement qui suit. L'abreviation `redoubler la touche' permet
> d'appliquer la  commande a la ligne courante... et des lors, une abreviation
> comme 4yy se comprend tres bien (4 lignes a partir de la ligne courante).

Et pourquoi serait-ce « à partir de » la ligne courante et pas
« jusqu'à » la ligne courante ?  De toute façon, on a y3j pour faire
ça, et je ne sais pas si on peut honnêtement dire que le fait que y3j
soit pareil que 4yy est vraiment logique...

> Des lors, que 8y ne fasse rien est logique (commande pas finie), et yyyyyyyy
> ne fait jamais que begayer 4 fois la meme chose...

Et c'est pas ce que le 4 est censé dire, « répéter la même chose » ?

From madore@news.ens.fr
Path: eleves!not-for-mail
From: madore@news.ens.fr (GroTeXdieck)
Newsgroups: ens.forum.informatique.editeurs
Subject: Re: Emacs vs vim
Date: 10 Jun 1999 12:48:47 GMT
Lines: 42
Sender: madore@brick.ens.fr
Message-ID: <7joc7f$h14$4@clipper.ens.fr>
References: <7jjbu6$fuu$1@clipper.ens.fr> <7jjq83$bgg$1@twilight.efge.org> <7jk7bb$qh9$1@clipper.ens.fr> <7jkep4$2ai$1@clipper.ens.fr> <7jm8b1$heh$1@clipper.ens.fr> <7jn469$o8m$1@clipper.ens.fr>
NNTP-Posting-Host: brick.ens.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: clipper.ens.fr 929018927 17444 129.199.129.13 (10 Jun 1999 12:48:47 GMT)
X-Complaints-To: forum@clipper.ens.fr
NNTP-Posting-Date: 10 Jun 1999 12:48:47 GMT
X-Newsreader: Flrn (0.4pre2 - 05/99)
Xref: eleves ens.forum.informatique.editeurs:129

Eric Brunet in litteris (informatique.editeurs:109) scripsit :
> Oui, mais tu veux savoir s'il y a un espace à la fin de la ligne ou non.
> La méthode de vi pour te dire ça, c'est de faire en sorte que le curseur
> carré soit forcément sur un caractère existant (et donc tu ne peux pas
> mettre le curseur au delà du dernier caractère de la ligne, ce qui te
> permet de t'y retrouver). Une fois ceci admis pour le mode commande, tu

Sous Emacs comme sous tous les autres éditeurs visuels que je connais
à part vi, tu vois s'il y a une espace à la fin de la ligne en
regardant si le curseur va juste au-delà du dernier caractère visible
ou bien un cran au-delà.  Comme dans le mode insertion sous vi,
d'ailleurs.

> te rends compte que tu es obligé d'avoir une commande insert et une
> commande append (sinon il y a un endroit où tu ne peux pas taper), et
> comme on veut qu'une fois que tu es entré en mode insertion le
> comportement ne change pas selon que tu es en mode insert ou append, le
> curseur est obligé de se déplacer d'une case.

Soit.  Si on fait ça on considère qu'en mode commande le curseur est
un carré et qu'en mode insertion c'est un trait.  Mais alors il faut
tenir ce raisonnement jusqu'au bout et dh doit effacer deux caractères
(le caractère sous le curseur et celui juste à gauche) et dl aussi
(pour effacer juste un caractère, on a x de toute façon).

> Tu te plantes dans ton raisonnement parce que tu considères à tort que le
> mode principal de vi est le mode insertion. C'est faux, c'est le mode
> commande.

Je n'ai jamais supposé ça.  Le fait que tel ou tel mode soit principal
n'intervient pas dans mon raisonnement, de toute façon.

> Au fait, comment vérifie-t'on l'absence d'espace en fin de ligne sous
> emacs ?

Comme dans vi dans le mode insertion, ou comme dans n'importe quel
autre éditeur.  En notant le curseur par un accent circonflexe,

xxx^   <- Là la ligne se termine par xxx et je suis juste après (je ne
          peux pas aller plus loin)

xxx ^  <- Là la ligne se termine par une espace et je suis juste après