Discussion :

[Ekinoks]

Salut !

Ca fait quelque année que je programme en C & C++, d'abord sur Windows avec dev-c++ puis j'ai migré sur Linux et j'utilise maintenant Code::block (ou Kate à ma fac car Code::block n'y est pas installé :^/)

Mais je me rend conte que les éditeurs textes comme emacs ou vim sont très utilisé par beaucoup de programmeur du monde Linux !

Alors ma question est de savoir se que c'est éditeur on de plus que Kate ou que Code::Block ?
C'est éditeurs utilisé par les "gourous" de la programmation sont t'ils réellement plus efficaces que des éditeurs comme Kate ou Code::Block ? Ou alors es que se sont des éditeur dépassé et c'est juste les "vieux" qui n'arrive pas à s'en détacher ?

J'aimerais aussi savoir quel est la différence entre vim et emacs ?
j'ai beau chercher sur internet, mais je ne trouve que des trolls :^/
Les utilisateur de vim dissant vim est le meilleur et les utilisateur de emacs dissant que emacs est le meilleur sans vraiment trop d'argument ...

Alors qu'en est t'il vraiment de ces éditeurs de texte au design pour le moins étonnant ? ^^

Merci.

[gorgonite]

ils sont en standard sur tous les unix depuis nombre d'années... et tout ce qui vont un peu d'admin système les privilégieront

ensuite, ils sont hautement paramétrables (même si ELisp de Emacs est un peu chiant)

enfin, ils sont très légers

[Ekinoks]

Merci pour ta réponse gorgonite.

1) Ok, pour les standards ! (bien qu'il doit exister aussi des éditeurs de texte classique qui respecte les standard).
Mais pas tout le monde a besoin d'avoir des standards respecté...

2) hautement paramétrables ? quoi de plus que les éditeurs classique ?
Avec un éditeur style Kate ou Code::Block, on peu personnaliser sa coloration syntaxique, le style des caractères, l'indentation, l'autocomplétition...
Je ne voie pas des chose paramétrable qu'un éditeur autre que vim / emacs ne puissent pas faire (c'est aussi peu étre par ce que j'ai jamais eu le choix)

3) Ouais, ça peu être un gros avantage si on a des très très vieux PC mais de nos jour presque tout les pc arrive à faire fonctionner un Kate sans constater le moindre lag...

[gorgonite]

1) Ok, pour les standards ! (bien qu'il doit exister aussi des éditeurs de texte classique qui respecte les standard).
Mais pas tout le monde a besoin d'avoir des standards respecté...

si tu bosses sur différentes machines... où que tu sois, tu y auras accès
et on est pas toujours admin de sa machine

2) hautement paramétrables ? quoi de plus que les éditeurs classique ?
Avec un éditeur style Kate ou Code::Block, on peu personnaliser sa coloration syntaxique, le style des caractères, l'indentation, l'autocomplétition...
Je ne voie pas des chose paramétrable qu'un éditeur autre que vim / emacs ne puissent pas faire (c'est aussi peu étre par ce que j'ai jamais eu le choix)

ça doit être équivalent... mais c'était pour dire qu'ils ont les mêmes fonctionnalités que ceux que tu citais

13) Ouais, ça peu être un gros avantage si on a des très très vieux PC mais de nos jour presque tout les pc arrive à faire fonctionner un Kate sans constater le moindre lag...

à moins d'être très très borné, tu devrais comprendre que chacun utilise des outils en fonction de ses gouts, et de sa formation... s'il a toujours été formé sur Emacs, pourquoi changer ? pour devoir recompiler son code::block à la main, parce que sa distrib ne l'a pas encore intégré ?

[Ekinoks]

si tu bosses sur différentes machines... où que tu sois, tu y auras accès

Oui, effectivement, ça c'est plutôt cool comme truc.

ça doit être équivalent... mais c'était pour dire qu'ils ont les mêmes fonctionnalités que ceux que tu citais

Ok

à moins d'être très très borné, tu devrais comprendre que chacun utilise des outils en fonction de ses gouts, et de sa formation... s'il a toujours été formé sur Emacs, pourquoi changer ? pour devoir recompiler son code::block à la main, parce que sa distrib ne l'a pas encore intégré ?

Oui oui ! ça je le comprend très bien que des personnes ayant toujours codé sous vim / emacs y reste !
C'est pas ça que je cherche a comprendre ^^
C'est plutôt l'inverse, je cherche plutôt à savoir si j'aurais un avantage à passer de mon Code::Blocks à un vim ou emacs...

Car si ces éditeurs son si apprécié des développeurs c'est peu être du à deux chose :
- Soit ces éditeurs sont bien mieux que des éditeurs classique pour programmer !
- Soit ces éditeurs sont équivalent au autre et ce sont juste les personnes qui se sont habitué à ces logiciels est donc y reste.

Dans le premier cas j'apprendrais à utiliser l'un de ces logiciels (car ça réclame une grande période d'apprentissage car peu classique)
Dans le seconds cas je resterais avec mon Code::Blocks


C'est pas que j'aime pas Code::Blocks car je le trouve cette éditeur vraiment excellent ! =)
Mais si il existe des éditeurs de texte me permettant de me simplifier la vie lorsque je conçois un programme autant l'utiliser ^^

[igor24]

salut,
Pour tout dire, j'utilise codeBlocks, parce qu'il est simple d'utilisation. J'utilise un peu vim, mais juste pour editer des petits fichiers. Bon, pour ce qui est d'Emacs, j'envisage vraiment de m'y mettre, car c'est un univers à lui seul. J'ai lu 2, 3 articles sur Emacs, je suis vraiement surpris des fonctionnalités qu'il offre. Lisez un peu ça.

A mon humble avis, je crois que Emacs ou VI sont indispensables pour un linuxien.

[granquet]

j'utilise vim (et pas cette m***e d'emacs) car j'en ai marre de passer mon temps a cliquer partout.
quand je code, j'ai les mains sur le clavier, et vim me permet de garder les mains sur le clavier du debut a la fin de mon developement, pour peu qu'on ait un WM clavier friendly (pas gnome//KDE quoi !), tu peux jeter ta souris

selon moi:
avantages:
-plus de perte de temps a passer du clavier a la souris.
-operations sur N lignes//colonnes facilement. (vas rajouter un # sur la premiere colonne des 10 lignes avec Kate )
-deplacement du curseur en fonction des "mots"/lignes/colonnes
-integration des reg-exp
-on passe pour un fou, mais un fou qui code plus vite que ses camarades sur clickodromes
-et on retrouve vi // vim partout. si je me retrouve sous solaris (pas sous windows, j'y touche plus) connecté via ssh a un PC : hopla, je peux bosser, j'ai mon vim

inconveniant:
-apprentissage !

[Gnux]

ils sont en standard sur tous les unix depuis nombre d'années... et tout ce qui vont un peu d'admin système les privilégieront

ensuite, ils sont hautement paramétrables (même si ELisp de Emacs est un peu chiant)

enfin, ils sont très légers

s/elisp/vimscript
Perso je trouve que le gros désavantage de Vim est de ne pas avoir de langage de script aussi puissant que lisp. Le seul truc énervant pour Elisp c'est le dynamic scoping mais à part ça...
Vim est plus léger que Emacs et convient mieux je trouve aux petites modifs. Pour des fichiers de config j'utilise plus facilement Vim, pour le reste c'est plus souvent Emacs.

[Ekinoks]

Merci pour vos réponses

igorIgor : Merci pour le lien =), mais à part l'historique du logicielle il ne développe pas trop ces avantages

Dark Ebola : Donc d'âpres toi, il est plus rapide de coder sans sourie en utilisant seulement des raccourcis clavier ?
Es que par exemple c'est pas galère de se déplacer dans tout les fichiers sources sans trop savoir se dont on cherche ... ?

[Franck.H]

En voilà un sujet intéressant avec des questions que je me souvent posé. Je comptais justement commencer d'ici peu de temps l'apprentissage de Vim mais la question que moi je me pose, c'est s'il est possible d'éditer plusieurs fichiers sur la même fenêtre ?

Le topo, c'est que pour des petits développement j'utilise souvent Gedit mais ce n'est pas toujours bien, surtout quand on veut lire un fichier édité avec Gedit sur Vim ! Après, l'avantage de certains éditeur donc Kate, Gedit, Code::Blocks, etc... permettent d'ouvrir plusieurs fichiers dont chacun d'eux se situe sur un onglet ce qui permet de naviguer ma foi assez rapidement d'un fichier à l'autre.

Ce que je recherche en premier lieu, c'est ce type de possibilité ! Est-ce existant sous Vim et/ou Emacs ?

[BlaireauOne]

(...) mais la question que moi je me pose, c'est s'il est possible d'éditer plusieurs fichiers sur la même fenêtre ?

(...) Après, l'avantage de certains éditeur donc Kate, Gedit, Code::Blocks, etc... permettent d'ouvrir plusieurs fichiers dont chacun d'eux se situe sur un onglet ce qui permet de naviguer ma foi assez rapidement d'un fichier à l'autre.

Ce que je recherche en premier lieu, c'est ce type de possibilité ! Est-ce existant sous Vim et/ou Emacs ?

Avec la dernière version de vim (7.0), tu peux charger tes fichiers dans des onglets.
Autre grand intérêt de vim (qui existe peut-être dans les autres éditeurs) est le mode "diff" qui permet de comparer les différences entre 2 fichiers ouverts, côte-à-côte (les plages identiques étant cachées par le mode "repli").
Pour ceux qui sont allergiques à la gestion des modes "commande" et "insertion", ils peuvent ajouter l'interface "cream" qui rend "vim" plus convivial pour les néophytes.
Si Emacs est beaucoup plus qu'un simple éditeur, il est aussi beaucoup + lourd (20 Mo) alors que vim fait 6 Mo.


http://www.framasoft.net/article999.html
http://cream.sourceforge.net/features.html
http://cream.sourceforge.net/screenshot2.html

[millie]

Je plussoies gorgonite.

Il est vrai que sur certaines vieilles machines où tu n'es pas forcement administrateur, tu n'as accès qu'à des éditeurs tel emacs ou vim (même pas de gedit).

Mais personnellement, chez moi, je prefère travailler sous code::blocks (qui m'offre toutes les fonctionnalités dont j'ai besoin), ou avec un autre éditeur sympatique (gedit ou autres choses sous windows). Ceci car j'ai l'habitude des raccourcis classique des applications de ce genre (ctrl S, ctrl C/V, ctrl F...). Même si il est nécessaire de changer d'EDI lorsque l'on change de langage (contrairement à emacs), il faut avouer que le changement n'est en général pas violent.

Les éditeurs comme code::blocks sont en général très simple à prendre en main (une touche, ça compile tout seul et ça créait le makefile), je ne souhaite pas me prendre la tête quand je fais des choses (donc, ça va très bien pour moi).


Maintenant, il peut arriver qu'il soit nécessaire d'utiliser des EDI en mode purement texte (vim, emacs -nw) notamment lorsque je me connecte sur des serveurs ssh et que je dois modifier des fichiers directement sur le serveur (et que je ne souhaite pas faire de transfert de fichier). Trouvant vim pas humain , j'utilise plutôt nano ou pico (enfin, j'irais pas tapper 100 lignes de code avec ça !).

[Ekinoks]

millie> Ha voila ! je suis exactement dans le même cas que toi !
j'utilise code::blocks qui est très simple a utiliser (makefile auto, compilation en une touche) et avec des raccourci clavier classique Ctrl-C Ctrl-V Ctrl-X Ctrl-F...
La question est de savoir si il est plus rapide de programmer avec un emacs / vim ou avec un code::blocks ? et si il est possible de personnaliser les raccourcis clavier de emacs / vim ?

et es que xmacs / vim on aussi des outils permettant de créé des makefile automatiquement ? (car ça fait gagner beaucoup de temps de ne pas avoir à créé un makefile a chaque foi)...

[millie]

et es que xmacs / vim on aussi des outils permettant de créé des makefile automatiquement ? (car ça fait gagner beaucoup de temps de ne pas avoir à créé un makefile a chaque foi)...

En fait, vim et emacs ne permet pas de faire cela automatiquement. Il faut utiliser des outils supplémentaires comme automake, autoconf, autoheader, aclocal...

C'est de toute façon ce qu'il faut souvent faire lorsque l'on veut permettre à quelqu'un d'autres de compiler le programme : (les commandes : ./autogen.sh, ./configure (qui permet de regarder ou se trouve les bibliothèques), make, ou d'autres choses).Mais ces outils n'ont pas de rapport direct avec emacs ou vim en tout cas.


En tout cas, de mon point de vuel. J'arrive beaucoup plus vite avec code::blocks qui bénéficie de toutes les fonctionnalités dont J'ai besoin. Et que je connais.

[granquet]

Dark Ebola : Donc d'âpres toi, il est plus rapide de coder sans sourie en utilisant seulement des raccourcis clavier ?
Es que par exemple c'est pas galère de se déplacer dans tout les fichiers sources sans trop savoir se dont on cherche ... ?

alors oui c'est plus rapide, parce que tu ne lache pas ton clavier.
quand on tappe avec ses 5 doigts de ses deux mains, c'est assez emmerdant d'en perdre une moitié sur la souris pour faire des choses aussi triviales que selectionner un bout de texte, ou aller au mot suivant, se deplacer a la fin de la ligne ...

si tu sais pas ce que tu cherche, jpeux rien faire pour toi, desolé

[gege2061]

Maintenant, il peut arriver qu'il soit nécessaire d'utiliser des EDI en mode purement texte (vim, emacs -nw) notamment lorsque je me connecte sur des serveurs ssh et que je dois modifier des fichiers directement sur le serveur (et que je ne souhaite pas faire de transfert de fichier). Trouvant vim pas humain , j'utilise plutôt nano ou pico (enfin, j'irais pas tapper 100 lignes de code avec ça !).

Idem, sauf que je n'ai pas le choix, sous Aix c'est Vim donc là je m'en sors, par contre sous VMS on a le droit à ed

Sinon pour une utilisation perso je préfère vim, parce que !

Je l'utilise essentiellement pour faire de l'admin, ça évite d'avoir à switcher pour lancer une commande ou lorsque que le serveur X ne veux pas démarrer.

Pour une utilisation plus classique je suis plus gedit ou anjuta pour les gros développements mais j'aimerai bien apprendre à me servir sérieusement de vim

[Luc Hermitte]

Bonsoir.
Je m'invite à la discussion.

J'ai commencé à coder il y a bien longtemps en Basic sur TO8, puis GWBasic et Basica. Ils avaient leurs propres éditeurs intégrés. Puis j'ai longtemps utilisé les éditeurs de Borland qui accompagnaient Turbo Pascal.
Puis un jour, j'ai dû utiliser vi (pas vim) pendant quelques années à l'école. Qu'est-ce que j'avais pu le maudire. Et pourtant, de fil en aiguile, je me suis mis à penser mon édition de code en modal.
Ce n'est que naturellement que j'ai glissé vers vim le jour où je voulais avoir des mappings différents qui soient spécialisés pour chaque langage.

En vrac, les choses que j'apprécie sont :

- La modalité. Soit on adore, soit on déteste. Perso, je suis devenu accro, et je serais bien incapable de m'en passer.
- La souris n'est pas nécessaire (pas un click-o-drome), mais supportée
- Je connais beaucoup de combos (je ne vois pas de terme mieux adapté). J'ai compris leur logique (mnemo-technique). Accessoirement, elles n'exigent pas d'avoir des doigts souples (on enfonce deux touches à la fois grand maximum, sauf perversion qui nous fait configurer l'outil autrement)
- Les regex sont à portée de main, et les deux commandes :s(ubstitute) et :g(lobal) sont tout simplement géniales
- C'est multi-langage. Je m'en sers vraiment pour tout. C++, perl, (La)TeX, ..., et même pour éditer mes mails, ou encore pour exploiter des fichiers de logs de plusieurs centaines de mega (vim roxe pour cela)
- C'est complètement multi-OS. Je m'en sers sous windows, linux, solaris, et je sais qu'il marche très bien sur quantité d'autres plateformes. Et même quand la dernière version n'est pas installée, c'est vraiment vite fait, et sans avoir besoin d'être admin.
- J'ai régulièrement jusqu'à 20 fichiers d'ouverts simultanément (vive les très grands écrans) et je bosse sur un projet de quelques centaines de fichiers. Et sans explorateur. Je n'ai qu'à taper un bout du nom d'un fichier ou d'un identifiant pour l'ouvrir. Les onglets sont apparus récemment, mais je n'en ai pas encore ressenti le besoin.
- Le diff dont parle BlaireauOne, on peut le comboter avec CVS/SVN. Malgré l'âge respectable de vim, ce sont les outils de mes petits collègues qui me paraissent néanderthaliens.

Quoi d'autre? Je maintiens un nombre pas si négligeable de (ft/)plugins pour vim. Ils tournent essentiellement autour du développement en C++. Sans être complet, le langage de script (vimL) est simple et donne accès à toutes les fonctionnalités de vim. Ceux qui préfèrent peuvent coder des plugins en ruby, python ou perl.


Les (gros, ou pas) manques de vim:
- la gestion des événements est un peu limitée (on est encore loin d'emacs)
- difficile d'abord
- il n'y a pas le support de grosses boites qui vont fournir de vrai systèmes d'analyse du C++ à la volée. Il n'y a guère que VC++ qui dispose d'une complétion intelligente de qualité. Tous les autres outils reposent sur ctags -- ancien sous-projet de vim.
- une seule police à la fois (=> pas de super affichage des formules mathématiques dans un document LaTeX)

PS: quand un éditeur de texte permet de jouer à sokoban ou tetris, il n'y a rien que l'on ne puisse faire avec.

[Franck.H]

J'allais oublier le plus important, exite t-il des livres (pour Vim 7) ou des tutoriels qui permettent d'apprendre à l'utiliser (et en français) ?

[Ekinoks]

Merci pour ce portait de vim Luc :^D

Effectivement dit comme ça, ça a l'aire plutôt cool comme truc ! =) ça donne envie de lire quelque tuto pour essayer la bette :^p

Par contre dans les manque de vim tu a dit :

- la gestion des événements est un peu limitée (on est encore loin d'emacs)

Alors ma question serais de savoir, quel es le mieux vim ou emacs ... ?
enfin, il ne doit pas y avoir de mieux mais plutôt quel sont les différences et pour quel genre d'utilisateur l'un ou l'autre ?
Est es que le passage de vim a emacs (ou inversement) est facile ?

[souviron34]

Personellement j'utilise vi uniquement pour de petits fichiers, et la plupart du temps en mode "panic", c'est à dire quand, pour une raison x ou y, le boot se passe mal, et pas accès au graphisme (prompt système sans interface graphique...).

Très pratique, et un des seuls (oublier Code:: etc... car avec graphisme) à pouvoir te tirer d'un de ces mauvais pas (boot manuel par exemple, ou pas à pas).

En ce qui concerne l'édition en général, en mode "graphique normal", j'utilise xemacs ....

Très pratique (beaucoup plus que dev.. ou code ou.. car pas de sous-fenêtres inutiles). Tu peux faire ta partition visuelle comme tu veux (plusieurs fenêtres dans la même, l'une en dessous de l'autre, l'une à côté de l'autre). Très puissant : plein de fonctionalités (rehaussement variable de la syntaxe, compilation, différences de fichiers, et j'en passe) tout en étant souple (tu peux "bypasser" les défauts).
Léger. Existant sous tous les *n*x.


Et pour le debug ddd, car extrêmement puissant et convivial.