Discussion :

[nschoe]

Bonjour à tous,

Voilà, je me posais une petite question, que je qualifierai de "méthodologique". Voilà, on sait tous qu'on peut écrire du code C++ dans un simple notepad, c'est moche, ce n'est pas pratique, mais ça fonctionne. Pour simplifier l'utilisation au quotidien, il existe des IDE, qui gèrent (pour la plupart) l'auto-complétion et la coloration syntaxique, et qui intègrent des fonctionnalités de débbugage, de compilation via un simple bouton et d'exécution.

Maintenant je voudrais parler d'éditeurs en console (je prendrai l'exemple de vim, mais je parle également d'emacs ou autre), je voulais entendre (ou plutôt lire ) vos avis quant à l'utilisation de vim (rappel, par "vim" j'entends "éditeur en console"). Je lis souvent que vim est un très bon éditeur, qu'il possède pleins de fonctions etc, mais je voudrais savoir quels sont les avantages de coder avec vim et de compiler "à la main". Pour la compilation "à la main", je peux comprendre aisément : on peut définir nos propres options, etc. Mais quel est l'intérêt de coder en console avec vim ?

Notez que je ne suis absolument pas en train de dénigrer vim ou de dire que c'est moins bien, j'aimerais juste comprendre (et essayer par la même occasion) les avantages de vim. Parce que pour le moment, lorsque je code avec vim, je me rends compte de la coloration syntaxique, mais je ne vois ni auto-complétion (pas trop grave me direz-vous), ni gestion de plusieurs fichiers à la fois. De plus, la fenêtre est relativement petite (taille de la console).

Donc ce que j'aimerais à travers ce post, ce n'est surtout pas me faire d'ennemis ^^, mais de comprendre ce qui vous pousse à bosser sous vim ; comprendre comment vous utilisez vim, les astuces, les avantages, si vous mettez la console en plein écran ... bref comment vous gérez un projet lorsque vous programmez, parce qu'en plus, il n'y a pas, comme sur un IDE, un arbre avec tous les fichiers du projet.

Donc voilà, si vous pouviez m'éclairez quant à l'utilisation d'un tel procédé, je vous serais très reconnaissant !

Bien à vous, Dreepser.

[JolyLoic]

Les principaux arguments que j'ai pu entendre sont :
- La rapidité et la légèreté du programme
- L'existence d'un mode qui permet de ne jamais avoir à maintenir une touche appuyée (genre shift-quelquechose, ctrl-quelquechose...), ce qui est moins fatiguant pour les doigts.

Tous les autres arguments que j'ai pu entendre étaient liés à une mauvaise connaissance des alternatives...

[nschoe]

Merci de votre réponse !

Mais par exemple, une chose qui je trouve pèse en la faveur des IDEs : il n'y a pas une vue d'ensemble des fichiers de notre projets, ni quelque chose qui remplacerait les onglets : lors de la modifications fréquente d'une classe et qu'il faut basculer systématiquement entre le .cpp et le .h, ça veut dire qu'on doit fermer vim, puis ouvrir l'autre fichier, se déplacer au clavier jusqu'à l'endroit ou écrire, puis re-fermer, ré-ouvrir le premier, se re-déplacer ...

Est-ce que ça ne devient pas génant pour des fichiers qui ont une taille conséquente ?

[Florian Goo]

Bonjour,

Ce qui fait la puissance de vim (et emacs), ce sont les plugins (appelés scripts pour vim).
Vim sorti d'usine n'est effectivement pas très pratique pour coder (pour, entre autres, les raisons que tu as évoquées). Pour avoir un environnement au moins aussi agréable qu'un EDI, il te faut donc installer des scripts.

Par exemple :

il n'y a pas une vue d'ensemble des fichiers de notre projets

Script Project : http://www.vim.org/scripts/script.php?script_id=69

ni quelque chose qui remplacerait les onglets

Vim 7 intègre en natif les onglets, mais personnellement je préfère les explorateurs de buffers.
J'utilise minibufexpl : http://www.vim.org/scripts/script.php?script_id=159

il faut basculer systématiquement entre le .cpp et le .h

Plugin A (pour Alternate) : http://www.vim.org/scripts/script.php?script_id=31


Pour la compilation et l'affichage des lignes où se situent les éventuelles erreurs, il y a l'indispensable mode quickfix (:h quickfix), intégré par défaut dans Vim.

Pour l'autocomplétion et autres joyeusetés, pareil, un script !

Enfin, pour la compilation « à la main », je te conseille CMake (voir ma signature pour un cours d'initiation).


Mais pour répondre à ta question d'origine (pourquoi vim/emacs c'est mieux) : vu que tout se fait au clavier, avec des commandes bien plus puissantes que les raccourcis clavier des éditeurs graphique (par puissante, j'entends : une commande de 2/3 caractères fait ce que tu ferais en autant, voire plus de raccourcis clavier différents), tu vas au final beaucoup plus vite.
C'est configurable à l'extrême.
Comme dit Loïc, ça fait moins mal au doigts (pour vim en tout cas… emacs l'argument ne prend pas trop).
Et c'est effectivement bien plus léger qu'un EDI.

[koala01]

Salut,

Outre le fait que vim est hautement configurable et léger, on peut aussi noter que l'énorme avantage c'est... qu'il est d'office sur n'importe quellle distribution linux, y compris les plus anciennes, ou, suite à une installation minimale (ou peu s'en faut).

Si ce n'est pas vim, ce sera emacs

Tu as donc la certitude de l'avoir "toujours sous la main", là où les EDIs nécessitent à tout le moins un gestionnaire de fenêtre et que certains ne font même partie d'aucune distribution (Code::blocks, par exemple, n'est à ma connaissance intégré dans aucune distro)

En tant qu'utilisateur "final" de linux, cet avantage peut sembler léger, mais, si tu viens à devoir travailler avec un serveur de prod, sur lequel le "minimum indispensable" a été installé (bye KDE et autres Gnomes), ca prend tout son sens

[Goten]

Si tu es assez familier avec vim (comprendre que tu t'es tapé le vimtutor ^^)
tu peux lire ":h motion.txt" et ":h s"


Mais en effet la toute puissance de vim c'est les scripts qu'on trouve à foison...Sincérement après avoir testé vim j'ai beaucoup beaucoup de mal à travailler sur un EDI classique quand j'y suis obligé.

[nschoe]

Wow !
Merci à vous tous ! Comme je le pensais : j'étais plus qu'ignorant en la matière ! Je n'avais pas conscience des plugins, ni des possibilités de vim en fin de compte.

Je pense que je vais aller lire pas mal de trucs dessus, et me "tapper le vim tutor" . À vous entendre, ça a l'air vraiment intéressant, et c'est vrai que je voulais tester autre chose, comme ça c'est fait, enfin presque ^^

Je vais lire également le liens sur CMake.

Un très grand merci à vous, je passe le sujet en résolu, mais je reviendrais certainement poster mes impressions !

Encore merci !

[Jean-Marc.Bourguet]

Maintenant je voudrais parler d'éditeurs en console
(je prendrai l'exemple de vim, mais je parle également d'emacs ou
autre),

Je suppose que par console, tu entends terminal/mode texte? (Pour moi la
console est un terminal privilégié sur lequel s'imprime -- c'est plutôt un
terminal genre tty que VT52, comme ça on a une trace -- toutes les
informations de diagnostic; souvent la console est aussi le seul terminal
d'où on peut faire certaines opérations privilégiées).

Emacs s'il est capable de fonctionner sur un terminal est généralement
utilisé avec sa propre fenêtre dans laquelle il y a une gestion des fontes
et des images (vim a les deux modes, il a même un troisième mode qui n'est
pas plein écran -- et est donc utilisable sur un tty --, mais je ne sais
pas quel est la pratique commune). On l'utilise en mode terminal que quand
il n'y a pas le choix -- donc qu'un IDE n'ayant qu'un mode GUI n'est pas
une option. Par exemple quand on édite travaille sur une machine au bout
du monde -- quand ça m'arrive, même si je suis beaucoup plus fortement
emacs que vi, j'utilise parfois même vi si la liaison est lente pour son
mode en ligne plutot que visuel.

je voulais entendre (ou plutôt lire ) vos avis quant à
l'utilisation de vim (rappel, par "vim" j'entends "éditeur en console"). Je
lis souvent que vim est un très bon éditeur, qu'il possède pleins de
fonctions etc, mais je voudrais savoir quels sont les avantages de coder
avec vim et de compiler "à la main". Pour la compilation "à la main", je
peux comprendre aisément : on peut définir nos propres options, etc. Mais
quel est l'intérêt de coder en console avec vim ?

L'intérêt principal d'utiliser des éditeurs fortement configurable tels
qu'emacs ou vi, est l'existance de "modes" permettant de faciliter
l'écriture dans un langage ou un autre tout en étant suffisemment commun
pour que ce soit le même éditeur.

Notez que je ne suis absolument pas en train de dénigrer vim ou de
dire que c'est moins bien, j'aimerais juste comprendre (et essayer par la
même occasion) les avantages de vim. Parce que pour le moment, lorsque je
code avec vim, je me rends compte de la coloration syntaxique, mais je ne
vois ni auto-complétion (pas trop grave me direz-vous),

Il y en a dans emacs. Bien que ce soit vraisemblablement là où il a le
plus de manque par rapport à quelque chose d'intégré. Il a plusieurs
systèmes d'auto-complétion mais celui qui utilise le plus des données qui
ne sont disponibles qu'en parsant le fichier source (semantic) est à mon
sens trop lourd à utiliser pour ce qu'il apporte sur mes projets -- mais
tous les IDE que j'ai utilisé passent mal à l'échelle d'un projet de 40000
fichiers. Un avantage est que les autres types de complétion sont
disponibles pour n'importe quel langage, sans avoir à faire d'effort
d'adaptation.

ni gestion de plusieurs fichiers à la fois.

Emacs est capable depuis que je l'utilise d'éditer plusieurs fichiers à la
fois. Je doute que vim en soit incapable.

De plus, la fenêtre est relativement petite (taille de la
console).

Mes terminaux sont grands. Quand on utilise des émulateurs de terminaux,
il faut en choisir un bon.

Donc ce que j'aimerais à travers ce post, ce n'est surtout pas me faire
d'ennemis ^^, mais de comprendre ce qui vous pousse à bosser sous vim ;
comprendre comment vous utilisez vim, les astuces, les avantages, si vous
mettez la console en plein écran ... bref comment vous gérez un projet
lorsque vous programmez, parce qu'en plus, il n'y a pas, comme sur un IDE,
un arbre avec tous les fichiers du projet.

Un des problèmes de ces éditeurs, c'est qu'il faut passer un peu de temps à
les configurer. A peu près tout ce que tu dis impossible ne l'est pas, et
souvent était disponible avant que ce ne soit disponible dans des IDE.
Mais il faut le configurer, et parfois aller le chercher ailleur que dans
la distribution de base. Et une fois que tu as goûter à la possibilité de
configurer à ta mode, c'est difficile de s'en passer.

Je ne sais pas à quel point les EDI sont configurables; une configuration
aussi agréable que ce que j'ai est peut-être possible à faire. J'ai passé
je ne sais plus combien de temps(*) à essayer les IDE pour linux il y a
deux ans, bien souvent je n'arrivais purement et simplement pas à voir
comment les adapter à la structure existante de mon projet, les autres
avaient des performances tellement faibles qu'ils étaient inutilisables,
même en ayant déactiver au maximum tout ce qui pouvait être coûteux sur un
projet de 40000 fichiers. Je n'ai jamais atteind le point où j'aurais
regardé la facilité d'adaptation à ma sauce.

Dans la position de quelqu'un qui débute -- et pas sur un projet où il y a
un tel existant que c'est à l'EDI à s'adapter au projet plutôt que le
projet à l'EDI -- la situation est autre. L'EDI t'offre une solution clé
en main, mais vraisemblablement moins flexible.

Note: en parlant d'EDI, je ne parle que de ceux que j'ai essayé, donc qui
étaient disponibles pour Linux il y a deux ans. En particulier, je ne sais
pas à quel point ça s'applique à VC++ dont j'ai souvent entendu dire qu'il
sortait nettement du lot.

(*) Je sais que pour Eclipse, qui avait été le plus prometteur, j'ai essayé
pendant une semaine. Si après ce genre de période d'essai il n'y a pas
d'avantages clairs et qu'il y a toujours des inconvéniants majeurs (un step
dans le débuggeur faisait 10 s, montre en main) pour lesquels on n'a pas
une piste de solution, je ne vois pas de raisons de persévérer.

[Alp]

En effet, Vim et Emacs sont configurables et extensibles via leur langage de script respectif, VimL et Emacs Lisp (abrégé en elisp).

Je ne sais pas tellement comment ça se passe sous Vim, mais ce doit être analogue à Emacs... Tout est fait pour que tu puisses vraiment scripter ton éditeur, tout y devient paramétrable. Je suis actuellement en train de me refaire des scripts pour mon emacs pour tout ce qui touche à la compréhension du code. Note notamment que ce qui est remarquable, c'est que l'on obtient des choses comme "Aller à la déclaration" ou "Aller à la définition/l'implémentation" de VC++ dans Emacs, et surement dans Vim aussi (pour Vim, je te conseille les scripts de Luc Hermitte : http://code.google.com/p/lh-vim/). On peut avoir une vue en arborescence du projet, lancer une compil avec une touche, debugger, surfer sur internet, jouer, gérer ses mails, etc sans quitter Emacs (j'avoue que cela peut sembler tomber dans l'excessivité, mais c'est juste pour te signaler que c'est possible).

Bref, ce que n'aiment généramement pas les gens dans les éditeurs comme Vim & Emacs, c'est soit l'interface qui est à mon sens simple et efficace, sans bling bling graphique, soit le fait que l'on paraisse moins assisté que dans des IDE (en fait on peut se faire aider par Vim/Emacs comme dit plus haut), soit le temps qu'il faut y passer pour le configurer à son goût, voir l'étendre.

Donc c'est une question de goût, vraiment

[nschoe]

Et bien ! C'est ce que j'appelle une réponse !
Je vous remercie grandement, mais aimerait savoir quelques petites choses supplémentaires, étant donné que vous êtes clairement utilisateur d'emacs, j'aurais un peu de tous les avis comme ça.

Je suppose que par console, tu entends terminal/mode texte? (Pour moi la
console est un terminal privilégié sur lequel s'imprime -- c'est plutôt un
terminal genre tty que VT52, comme ça on a une trace -- toutes les
informations de diagnostic; souvent la console est aussi le seul terminal
d'où on peut faire certaines opérations privilégiées).

Je sais que ça sort un peu du sujet, mais puisque vous en avez parlé, je me permets d'approfondir : est-ce que vous pourriez m'expliquer la différence entre les deux, parce que je ne la comprends pas -et à vrai dire, je n'avais pas conscience d'une différence, pour moi les deux termes étaient synonymes.

Emacs s'il est capable de fonctionner sur un terminal est généralement
utilisé avec sa propre fenêtre

Est-ce que ça veut dire qu'il faut qu'il y ait un gestionnaire de fenêtre d'installé, ou est-ce que c'est une fenêtre "à la console" (pardonnez-moi pour l'expression) ? De plus -étant relativement débutant en milieu Unix, je me permets de poser la question, même si elle vous paraît idiote, pour lancer emacs dans sa propre fenêtre, est-ce que ça veut dire qu'il faut le lancer comme un programme depuis la console : " ./emacs " ?

L'intérêt principal d'utiliser des éditeurs fortement configurable tels
qu'emacs ou vi, est l'existance de "modes" permettant de faciliter
l'écriture dans un langage ou un autre tout en étant suffisemment commun
pour que ce soit le même éditeur.

Pour quelqu'un qui débute, est-ce que du côté d'emacs il y a des tutos, ou un site qui détaille / explique la démarche pour le configurer ?

Mes terminaux sont grands. Quand on utilise des émulateurs de terminaux,
il faut en choisir un bon.

Là, je ne saisis pas totalement, mais c'est peut-être dû au fait que je connais pas la définition de "Terminal" avec exactitude, pour moi le terminal, c'est ... la console, je ne sais pas si c'est la même chose. Et que veut dire "émulateur de terminal" ? Est-ce que vous êtes sous Windows et émulez la console (ou plutôt terminal) de Linux ?

Un grand merci pour votre réponse, je vais chercher de la doc chez vim et emacs et je vais essayer de tester les deux. Si d'autres ont des réactions, n'hésitez pas, c'est un bonheur pour moi que de lire toutes ces infos !

EDIT --
@ Alp :

Merci de votre réponse également : ça fait plaisir d'avoir autant de réponses. Vous mentionnez deux langages (un propre à emacs, l'autre à vim), qui sont pour faire des scripts. Est-ce que ce langage est compliqué et long à apprendre, est-ce qu'il est indispensable de le maitriser "conplètement" pour arriver à faire ses propres scripts ? Est-ce que ça vaut le coup d'apprendre un des deux langages ? Parce que je suppose que des personnes très expérimentées ont déjà réalisé des scripts bien plus complets que ce à quoi des débutants comme moi peuvent penser.

En ce qui concerne la différence entre vim et emacs, je suppose que le sujet est propice à troll, ce que je ne veux absolument pas, je ne demanderai pas lequel est le meilleur -bien entendu, juste savoir est-ce qu'il y en a un qui qui est plus orienté sur un langage que l'autre ? Est-ce qu'il y en a un plus simple à prendre en main au début ? Est-ce qu'il y a lieu de demander les principales différences entre les deux ?

Un grand merci à tous !

[Alp]

Rien que pour le site officiel :
http://www.gnu.org/software/emacs/ page officielle
http://www.gnu.org/software/emacs/manual/ => docs relatives à emacs : son utilisation, doc du langage "elisp" (cf mon post juste au-dessus), et doc de modules attachés à emacs, notamment...
Après, tu as l'emacs wiki, et pleins de gens qui mettent des scripts sur leurs pages persos, enfin tu découvriras tout ça par Google. Mais la doc officielle (consultable depuis Emacs directement !) est un excellent point de départ pour Emacs.

[nschoe]

Merci Alp, je vais aller jetter un coup d'oeil à ces liens.
Juste pour signaler : j'ai édité mon post au-dessus parce que je n'avais pas vu que vous aviez posté.

[Alp]

Merci de votre réponse également : ça fait plaisir d'avoir autant de réponses. Vous mentionnez deux langages (un propre à emacs, l'autre à vim), qui sont pour faire des scripts. Est-ce que ce langage est compliqué et long à apprendre, est-ce qu'il est indispensable de le maitriser "conplètement" pour arriver à faire ses propres scripts ? Est-ce que ça vaut le coup d'apprendre un des deux langages ? Parce que je suppose que des personnes très expérimentées ont déjà réalisé des scripts bien plus complets que ce à quoi des débutants comme moi peuvent penser.

Tout d'abord, comme tout langage, ils demandent du temps, de la lecture et de la pratique.
Ils ne sont pas fondamentalement compliqués mais ils ne sont pas comme le C++ ou autre. Par exemple, l'elisp est un langage basé sur le Lisp, qui est un langage fonctionnel. Il faut s'y habituer, mais rien d'insurmontable
Cela vaut le coup d'apprendre le langage de l'éditeur que tu auras choisi, oui.
Des gens ont écrit bien des plugins, oui, mais ils ne te conviendront peut-être pas, ou peut-être auras-tu besoin de les modifier (si la licence le permet)... Ou alors il n'en existera pas qui feront ce que tu veux, auquel cas il faudra que tu t'y attaques toi-même.

En ce qui concerne la différence entre vim et emacs, je suppose que le sujet est propice à troll, ce que je ne veux absolument pas, je ne demanderai pas lequel est le meilleur -bien entendu, juste savoir est-ce qu'il y en a un qui qui est plus orienté sur un langage que l'autre ? Est-ce qu'il y en a un plus simple à prendre en main au début ? Est-ce qu'il y a lieu de demander les principales différences entre les deux ?

Tout d'abord, il n'y en a à mon sens pas un meilleur que l'autre. C'est une question de préférence. Certains préfèrent l'un à l'autre parce que les raccourcis de base (et par extension ceux qui sont définis par les plugins) sont comme ceci alors que ceux de l'autre sont comme cela, etc. Les deux sont des éditeurs de texte (et de code) très génériques, sachant que selon le langage de programmation du fichier que tu édites, ils peuvent se transformer en "IDE" (selon tes plugins) pour ce langage. Ouvrir un autre fichier d'un autre langage transformera en un "IDE" pour cet autre langage, etc. Bref, ils ne sont pas attachés à des langages spécifiques.
Quand aux différences entre les deux, à part le langage qui permet de les personnaliser et les "raccourcis", je ne sais pas tellement, ne connaissant vraiment que Emacs, alors je laisserai parler sur ce sujet ceux qui ont utilisé en profondeur les deux.

Toutefois, (ce n'est que statistique) parmi les personnes que je connais et à qui j'ai fait essayé emacs et vim, la plupart ont mieux pris en main Vim au départ.

[JolyLoic]

En effet, Vim et Emacs sont configurables et extensibles via leur langage de script respectif, VimL et Emacs Lisp (abrégé en elisp).

Juste pour information, le fait d'être extensible n'est pas limité aux éditeurs indépendants, et par exemple, Visual Studio est entièrement extensible et programmable à travers un modèle objet en .NET.

Le fait est que beaucoup l'utilisent sans jamais l'étendre, parce que de base, il répond déjà à une bonne partie des besoins. Mais le fait que le langage d'extension soit le même/grandement compatible avec le langage de programmation peut aussi aider. Déjà, pas de nouveau langage à apprendre, ensuite, ça peut permettre des facilités. Par exemple, j'ai mis en place pour notre produit un cryptage des fichiers, et j'ai ajouté à visual studio une fonction qui utilise directement cette API pour décrypter ces fichiers quand on veut comprendre ce qui se passe.

[Alp]

Le fait est que beaucoup l'utilisent sans jamais l'étendre, parce que de base, il répond déjà à une bonne partie des besoins. Mais le fait que le langage d'extension soit le même/grandement compatible avec le langage de programmation peut aussi aider. Déjà, pas de nouveau langage à apprendre, ensuite, ça peut permettre des facilités. Par exemple, j'ai mis en place pour notre produit un cryptage des fichiers, et j'ai ajouté à visual studio une fonction qui utilise directement cette API pour décrypter ces fichiers quand on veut comprendre ce qui se passe.

Oui, j'ai d'ailleurs assisté à une session sur VS au Technet Tour à Marseille. Mais, et c'est mon opinion, ça ne vaut pas l'extensibilité d'emacs (et de ce que l'on m'a dit, vim)

[Jean-Marc.Bourguet]

Je sais que ça sort un peu du sujet, mais puisque
vous en avez parlé, je me permets d'approfondir : est-ce que vous pourriez
m'expliquer la différence entre les deux, parce que je ne la comprends pas
-et à vrai dire, je n'avais pas conscience d'une différence, pour moi les
deux termes étaient synonymes.

Remontons dans le temps. Les années 70. Un terminal c'est un clavier et
une imprimante ou un écran.

Sur un système typique, on avait un ordinateur connecté à une série de
terminaux, généralement placés dans des salles autres que celle où se
trouvait la machine -- cette dernière étant accessibles uniquement aux
opérateurs. La console était

- soit un terminal privilégié, dans la salle machine, sur lequel était
affiché tous les messages de diagnostic.

- soit quelque chose d'autres, mais disposant aussi d'un clavier et servant
plus ou moins à la même chose (par exemple la console d'un PDP-10 était
un ordinateur complet avec un processeur PDP-11, on pouvait arrêter le
PDP-10 et toujours faire des choses à la console).

Depuis, les choses ont changé avec l'arrivée des stations de travail. Il y
a alors un système d'entrée sortie privilégiée (généralement carte
graphique et clavier connecté à l'ordinateur; mais sur un serveur ce peut
être un terminal classique connecté à un port série, ou un émulateur de
terminal tournant sur un autre ordinateur, multiplexé entre les différents
port série des machines d'une ferme) qu'on peut appeler console. Et la
destination des messages de diagnotic peut toujours être un terminal qu'on
va appeler console.

Un terminal pour unix, c'est soit un périphérique connecté à travers un
gestionnaire de terminal, soit un "pseudo-terminal", une connection vers un
autre programme qui est gérée aussi par un gestionnaire de terminal. Le
gestionnaire de terminal est la partie de l'OS qui va transformer le
caractère 0x03 (CTRL-C) en un signal SIGINT. Parmi les terminaux "purs",
il y a donc la console (qui de plus en plus peut se comporter comme
plusieurs terminaux virtuels), d'éventuels terminaux connectés à des
liaisons séries. Les pseudo-terminaux sont utilisés principalement par les
connections réseau, les systèmes de fenêtrages (quand on lance un terminal
X, le programme terminal X est un bout du pseudo terminal, le shell qui
s'exécute dedans a ses entrée et sortie standards connectées à l'autre
bout).

Est-ce que ça veut dire qu'il faut qu'il y ait un gestionnaire de
fenêtre d'installé, ou est-ce que c'est une fenêtre "à la console"
(pardonnez-moi pour l'expression)? De plus -étant relativement débutant en
milieu Unix, je me permets de poser la question, même si elle vous paraît
idiote, pour lancer emacs dans sa propre fenêtre, est-ce que ça veut dire
qu'il faut le lancer comme un programme depuis la console : " ./emacs "
?

Je ne suis pas sûr de comprendre la question. Emacs se lance comme
n'importe quel autre programme. Si la variable d'environnement DISPLAY est
définie, il se lance en mode graphique sur le DISPLAY X ainsi désigné (je
crains que ce qui manque c'est une bonne compréhension de la manière dont X
fonctionne, mais ça fait encore un bon morceau).

Pour quelqu'un qui débute, est-ce que du côté d'emacs il y a des
tutos, ou un site qui détaille / explique la démarche pour le
configurer?

Il y a une aide en ligne bien complète. Utilisant un système hypertexte
qui date d'avant le succès d'HTML.

[Est-ce que ce langage est compliqué et long à apprendre, est-ce qu'il est
indispensable de le maitriser "conplètement" pour arriver à faire ses
propres scripts ?[/quote]

Celui d'emacs, c'est un lisp -- sa principale particularité c'est qu'il
fait partie des lisps à portée lexicale dynamique plutôt que statique. Les
lisps sont en général des langages assez simples à apprendre.

Est-ce que ça vaut le coup d'apprendre un des deux langages ? Parce
que je suppose que des personnes très expérimentées ont déjà réalisé des
scripts bien plus complets que ce à quoi des débutants comme moi peuvent
penser.

Mais trop souvent répondant mal aux besoins des débutants.

En ce qui concerne la différence entre vim et emacs, je suppose que
le sujet est propice à troll,

C'est un candidat sérieux à être le plus vieux d'entre eux (cherche "Editor
wars" dans Wikipedia pour en voir des restes, jusqu'au fait que "la
neutralité de cette article est disputée").

est-ce qu'il y en a un qui qui est plus orienté sur un langage que
l'autre ?

Non. Sauf qu'en cherchant dans les langages exotiques on va en trouver qui
ont un bon support d'un coté et pas de l'autre.

Est-ce qu'il y en a un plus simple à prendre en main au début?

Emacs est moins modal que vi -- donc plus proche de ce qu'un débutant a des
chances de connaître. Mais je connaissait déjà trop bien emacs quand j'ai
été introduit à vi pour avoir un avis objectif sur les opinions d'un
débutant.

Est-ce qu'il y a lieu de demander les principales différences entre
les deux?

vi est très fortement modal. Tapper i n'insère pas toujours un i. Emacs
l'est un peu moins... il est plus facile de prévoir quand tapper un i n'en
n'insère pas un, du moins dans sa configuration de base (il y a au moins
deux modes pour emacs qui émulent assez bien vi).

emacs s'étend principalement avec son langage (elisp). vi utilise plus
facilement des programmes externes.

[Obsidian]

vim pourrait être considéré aujourd'hui comme un très gros sac de raccourcis clavier. C'est un éditeur très puissant et très utile .. à tout ceux qui ont déjà l'habitude de l'utiliser ! La « courbe des temps d'apprentissage des éditeurs », un dessin assez célèbre, résume assez bien l'état de l'art :

http://dailyvim.blogspot.com/2009/02...omparison.html

Mais surtout, le « vi » originel existe depuis 1976 et est très largement répandu. C'est un peu le notepad des systèmes Unix. Il a été conçu à une époque où les interfaces graphiques n'existaient pour ainsi dire pas. Malgré tout, il a fait l'objet de formations du personnel dans les entreprises, etc.

Une caractéristique de vi est qu'il est conçu pour être utilisé exclusivement avec les touches classiques, Esc, et éventuellement Ctrl, ce qui le rend utilisable sur toutes les plateformes, sachant que Alt est à la base une spécificité du PC, et que les touches étendues telles que les flèches du curseur n'existent pas partout, et ne sont pas gérées de la même manière. Par exemple, tu peux utiliser vi sur un Minitel 1B ou 2 (le dernier m'a servi de console supplémentaire sur ma machine Linux pendant quelque temps). Ça te permet également d'être à peu près sûr qu'il soit utilisable au dessus d'une connexion série, par exemple.

Pour la console et tout et tout, peut-être développes-tu sous Windows. Sous Linux, les consoles virtuelles sont très utilisées, et les terminaux sous X-Windows encore plus ! Ils peuvent être redimensionnés à volonté et être aussi larges et denses qu'une fenêtre en mode graphique. vim peut quand a lui ouvrir plusieurs fichiers, gérer un certain nombre de buffers, et diviser sa zone de travail.

Enfin, comme on l'a dit, vim et emacs sont des éditeurs universels : ils servent à tout ouvrir et peuvent être facilement étendus. Il m'est arrivé d'écrire mon propre fichier de coloration syntaxique pour mettre en lumière des fichiers de log générés par mes applications.

[Jean-Marc.Bourguet]

Juste pour information, le fait d'être extensible n'est pas limité aux éditeurs indépendants, et par exemple, Visual Studio est entièrement extensible et programmable à travers un modèle objet en .NET.

Ça me semble assez lourd à mettre en oeuvre, alors que j'écris assez souvent de petites fonctions lisp qui ne sont utilisée que dans une session.

[nschoe]

Ho ho merci de vos réponses !

Et bien je pense qu'avec toutes ces infos, "it's up to me" comme on dit. J'ai déjà lu un petit tuto de base pour Vim, je vais maintenant lire vos liens sur emacs, et puis j'essaierais de me faire un opinion.

Encore merci à vous !

EDIT (je n'avais pas vu la deuxième page)
Merci beaucoup pour l'explication sur Terminal / Console. Je pense que j'ai à peu près compris.

Pour ce qui est de l'apprentissage de lisp, c'est noté, en fait je pense qu'il vaut mieux créer soit même (au début) un plugin certes plus petit, mais uqi fait ce que l'on veut tout en comprenant comment et pourquoi il le fait, plutôt que de pomper des plugins déjà fonctionnels dont on utilisera 2%.

@ Obsidian :
On m'a déjà parlé dans ce topic des buffers, mais qu'est-ce que c'est exactement ?

En tous cas, merci c'est un réel plaisir que de venir sur ce forum, et je pense que je vais venir de plus en plus souvent !

[Obsidian]

@ Obsidian :
On m'a déjà parlé dans ce topic des buffers, mais qu'est-ce que c'est exactement ?

Un buffer, d'une manière générale, en informatique, c'est une mémoire tampon. Donc, une zone d'attente dans laquelle arrivent les données écrites par une routine quelquonque en attendant d'être lus par une autre.

Dans le cas de vim, c'est l'espace mémoire dans lequel est lu le contenu du fichier que tu édites. Étant donné que tu peux éditer plusieurs fichiers à la fois, ceux-ci ont chacun leur tampon. D'autre part, en splittant l'écran, tu peux avoir plusieurs fenêtres te permettant de visualiser différents fichiers, ou bien différentes parties du même fichier.

Les éditeurs modernes proposent quasiment tous ces fonctions, bien sûr. La différence est que, outre le fait que les clones de vi gèrent cela depuis bien longtemps et ce, sur des terminaux qui ne proposent pas de facilités graphique, ils te permettent de manipuler toi-même et de façon assez avancée les différentes fenêtres et les différents buffers, de manière complètement indépendante.

Ainsi, si tu ouvres le fichier foo.txt avec vim, tu vas le voir sur l'écran entier. Si tu tapes Ctrl-V S, tu vas diviser la fenêtre en deux. Si, de là, tu édites un second fichier en tapant :e bar.txt, son contenu va occuper une des deux fenêtres. Si tu divises cette fenêtre verticalement par exemple, avec Ctrl-W V, tu as trois fenêtres et deux fichiers en mémoire. Donc deux buffers.

Tu peux afficher la liste des buffers en cours avec :ls et choisir ensuite quel buffer tu veux affecter à quelle fenêtre. Si tu tapes :1b, la dernière fenêtre qui affichait le second fichier « zappe » sur le premier.

L'avantage est que tu peux travailler sur un buffer sans qu'il ait besoin d'être affiché à l'écran. Tu peux aussi ajouter dans la liste un nouveau buffer associé à un fichier (existant ou non) sans avoir besoin de le charger. Il le sera qu'au moment où tu « entreras » dedans.

Le contenu de ces différents buffers peut alors servir à tout et n'importe quoi. Il y a un anonyme qui sert entre autres aux copiers-coller, un buffer peut également servir de source pour une macro (tu mets plein de commandes vim dans ton buffer et tu les exécute en une fois en invoquant son nom), etc.

En tous cas, merci c'est un réel plaisir que de venir sur ce forum, et je pense que je vais venir de plus en plus souvent !

Et tu seras le bienvenu.