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é.

[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.