@ Holt : je faisais un comparatif GEdit / Geany
et oui certaines (mais pas toutes) boucles foireuses sont dures à tuer issues de GEdit ( il y a deux ans, ça a peut être changé, on me dira ...)

Je pense aussi aux élèves du lycée à qui on propose désormais de l'algo, (ISN).

Je vois mal un prof en lycée partir avec Vim ou Emacs (que je sais meilleur, déjà dit) avec sa classe de gros débutants qui partent pas pour faire des études d'info.


Ce n'est qu'un avis, bien motivé certes, mais en rien un troll. Merci de rester courtois.

Si tu crois que tu peux enseigner à des lycéens en leur envoyant direct un nouveau langage, un éditeur "non naturel" (via 99% de leur expérience : je cherche un menu à la souris pour cliquer ).
Alors chapeau... (mais je vois que tu es déjà équipé)


Si tu relis correctement mon post, tu voudras bien m'objecter les "autres" points, stp. Merci.

-----
Et sinon 100% d'accord pour étudiant en info => Vim ou Emacs.

Citation

Si tu crois que tu peux enseigner à des lycéens en leur envoyant direct un nouveau langage, un éditeur "non naturel" (via 99% de leur expérience : je cherche un menu à la souris pour cliquer ).

Je pense que ce que Holt a mentionné, c'est qu'Emacs avait aussi un pendant graphique avec, en plus des raccourcis clavier, des menus comme dans n'importe quel éditeur graphique (donc une version user-friendly). Et je confirme que Vim aussi : ça s'appelle GVim, et c'est accessible sous Ubuntu avec les paquets vim-gnome ou vim-gtk.

Cela dit, ne prenons pas la mouche : oui, nous sommes en train de troller sur les éditeurs et les EDI et c'est probablement l'un des plus vieux trolls du monde. Assumons-le, mais essayons d'en sortir des infos utiles.

bah surtout qu'autant vim a un coté déroutant et non-naturel par rapport aux editeurs classique (le coté modale), autant emacs si tu es débutant, ça ne pose pas de problème vu que dans la fenetre, tu tape, ça écrit.
La seul différence entre emacs et gedit est que suand tu as 3 mains de 8 doigts, tu peux lui demander de faire n'importe quoi. Mais en debutant tu peux t'en servir sans tuto

Citation

1) lorsqu'on lance un script qui bloucle à l'infini, il est plus délicat de tuer son appli, avec geany, ça marche.

Faux, donc 0-0

Citation

2) lorsqu'on a une ligne gigantesque (un big tableau sur une ligne),
oui je sais c'est pas bien, mais ça m'arrive souvent.
GEdit rame à mort avec un gros fichier et bugg un peu sur les grandes lignes.
Geany ne bronche pas. 2-0

Gedit t'apprends les bonnes manières, donc 0-1

Citation

2 bis) Lancer un script avec Geany c'est F5, et pi c tout. Avec GEdit, il faut éditer un fichier de préparation. 3-0.

Gedit et console, touche du haut et c'est tout, donc égalité, score final 0-1

Citation

Proposer Vim ou Emacs à des lycéens pour une classe d'algo est àmha simplement barjo !!! (Mais je concède que ce sont les meilleurs pour les pro)

barjo est peut être un mot fort, mais je suis d'accord sur le fait qu'une personne choisie ses priorités, et si c'est python, il est difficile d'apprendre deux choses complexes à la fois et tout dépendra du temps d'apprentissage imposé.

Citation

je ne vois rien de meilleur que Geany

Ben si Gedit

Quand je parle de grande ligne, je parle de 30000 caractères (mode gros bourrin qui hardcode quelques valeurs), là GEdit est total perdu. 1 - 0

GEdit rame à mort à l'ouverture, Geany est vif comme l'éclair. 2 - 0

Avec Geany, on a aussi la sélection rectangulaire (Ctrl + sélection à la souris), pas GEdit. (Je l'utilise rarement, c'est vrai) ( 2+ - 0 )

Quand je parle de boucle à l'infinie, ajoute un tableau qui bouffe toute la RAM et met à genou ton OS. Va le tuer facilement dans la console de GEdit : il te faut 3 minutes. (avec Geany, tu as un terminal indépandant qui s'est ouvert, facile à tuer). 3+ - 0

Va changer ta palette de couleur avec GEdit !!! (facile avec Geany) 4 - 0
(j'entends par là : faire du tuning sur les palettes prédéfinies)


---

J'étais gros fan de GEdit, avant, mais j'ai trouvé mieux.
Trouve un truc mieux dans GEdit que Geany n'a pas. J'attends.

Citation

Quand je parle de grande ligne, je parle de 30000 caractères (mode gros bourrin qui hardcode quelques valeurs), là GEdit est total perdu.

Ouais enfin moi si je vois une ligne comme ça pour déclarer un tableau, soit je ferme tout de suite le fichier, soit c'est un code que je DOIS vraiment lire et à ce moment là je la remets en forme automatiquement (gqap). Un fichier texte ne devrait JAMAIS contenir une ligne aussi longue.

Une ligne de 30k caractères c'est une mauvaise pratique... Au pire dans un fichier 'data' tu t'en fous, mais dans ce cas t'as jamais à l'ouvrir avec ton éditeur.

Gedit est rapide? Autant que Vim?

Sélection rectangulaire: très pratique, dans vim ^V.

^C, killall, kill -9 FTW.

Coloration syntaxique dans vim très simple à modifier.

'fin bon tout ça pour dire qu'il faut arrêter le fanboyisme. En toute objectivité on peut dire que vim/emacs sont plus puissant que geany (cf les arguments de nohar par exemple).

Je bosse sur le juge en ligne SPOJ ( et on ne peut soumettre qu'un fichier par problème ), ceci explique ma pratique inadmissible par ailleurs.
Mais bon, c'est comme ça, et GEdit s'est mangé son exit(1) à cause de ça principalement.

OK pour Vim/Emacs qui sont plus forts, tout le monde le sait, je l'ai déjà dit aussi. Mais va pas mettre ça à des petits lycéens, pitié pour eux.

Mais tu as déjà essayé ? autant vim je peux comprendre a cause du fonctionnement modal, autant emacs il est pas plus compliqué a prendre en main que gedit de prime abord

Évitons de partir dans un gros troll poilu, autant le débat graphique/console était intéressant autant celui sur Gedit/Geany est légèrement ... inintéressant (avis totalement personnel).

Personnellement j'essaye de me mettre petit à petit sur Vim, surtout depuis le début de mon projet. Je suis un lycéen, mais c'est vrai que la majorité de ceux qui font ISN dans ma classe sont un peu perdu ... même avec Code::Blocks Donc j'ilagine même pas avec Vim !

[troll]
Ça apprendra au prof à leur apprendre le C plutôt que le python ...
[/troll]

Pour ma part, je développe aussi sous vim. Pourquoi ? Quand on programme en java (android oblige), python et C++, avoir tout de réuni dans un seul outil est super. Vim, une fois ses contrôles claviers maîtrisés est très pratique / rapide (5>> par exemple pour indenté 5 ligne à la suite).

Quand, à coter de vim, on utilise git, curl (pour envoyer un bout de code par internet rapidemment), gdb, whatelse en console tout en testant son programme, il n'y a pas mieux. De plus, comme la si bien dit nohar, on ne programme généralement pas que dans un langage par projet, mais avec plusieurs (par exemple le xml couplé au python). Vim gère sa très facilement, change sa manière de coloration syntaxique etc.

La console est très pratique. Pour dire, je fais presque tout en console (chat, mail (mutt), programmation, mocp pour la musique). Le mode "graphique" ne me sert que pour internet, film et retouche photos par exemple (quoi que je ne retouche que très rarement des photos).

Sinon pour le débat en cours, vim est certes un très bon outil, mais il ne doit être présenté qu'à ceux qui veulent s'investir dans la programmation (amateur ou pro, on s'en fiche). Si ce n'est que pour faire deux/trois lignes de codes très rapidement (problème d'algo ?), il ne représente que très très peu d’intérêt.

édit : sinon pour ISN (étant moi aussi en terminal S), je trouve qu'il est beaucoup mieux (pour la suite de tes études) de prendre spé math. Tout ce que tu va apprendre en ISN s'apprendra par la suite très très rapidement (tandis que les maths sont moins rattrapable). Puis bon, au lycée (ISN) cela m’étonnerai que l'ont fait des programmes très poussé .

Citation : Francky_laH

Je bosse sur le juge en ligne SPOJ ( et on ne peut soumettre qu'un fichier par problème ), ceci explique ma pratique inadmissible par ailleurs.

Qu'est-ce qui t'empêche d'écrire ton tableau sur plusieurs lignes ?

Je ne sais pas si l'overhead dû au fait que ça donne plus de lignes à lire à l'interpréteur ne serait pas compensé par le fait qu'il doive réallouer son buffer de lecture pour qu'il fasse 30Ko, mais dans tous les cas, si c'est vraiment cette problématique qui te bloque, alors je trouve vraiment très dommage que ça puisse en arriver là.

Citation : FirstZero

Pour ma part, je développe aussi sous vim. Pourquoi ? Quand on programme en java (android oblige), python et C++, avoir tout de réuni dans un seul outil est super.

Autant vim/emacs pour un langage comme Python, je comprends, autant pour Java ça m'étonne déjà plus.
Est-ce qu'il y a moyen de paramétrer ces éditeurs pour obtenir une facilité d'utilisation du niveau d'un IDE dédié ? (compilation automatique, signalisation des erreurs en temps réel, auto-complétion sur les classes, méthodes et champs, détection de code mort, ...)

Citation : SpaceFox

Citation : FirstZero

Pour ma part, je développe aussi sous vim. Pourquoi ? Quand on programme en java (android oblige), python et C++, avoir tout de réuni dans un seul outil est super.

Autant vim/emacs pour un langage comme Python, je comprends, autant pour Java ça m'étonne déjà plus.
Est-ce qu'il y a moyen de paramétrer ces éditeurs pour obtenir une facilité d'utilisation du niveau d'un IDE dédié ? (compilation automatique, signalisation des erreurs en temps réel, auto-complétion sur les classes, méthodes et champs, détection de code mort, ...)

Compilation auto : non, mais tu peux paramétrer le :make de Vim pour qu'il utilise ant comme dans Eclipse quand il détecte que tu fais du Java.
Signalisation des erreurs en temps réel : soyons honnêtes, non. C'est sans aucun doute faisable, mais j'imagine mal quelqu'un se casser le c*l à écrire ce genre de plugin pour Vim.
Auto-complétion intelligente : OUI, complètement.
Détection de code mort : pareil que pour la signalisation des erreurs en temps réel. C'est faisable, mais je doute que quelqu'un l'ait déjà fait.

PS : J'ai répondu sans chercher les plugins en question sur le net.

Citation : Malikemal

, en attendant je vous propose de présenter celui que vous utilisez

Pour indenter un bloc avec Geany, c'est Ctr-I (I comme indent)
et pour désindenter, c'est Ctrl-U (comme unindent, et juste à gauche du I, facile)

ça j'utilise souvent, y a pas sous GEdit. 5 - 0


Pour rendre quelques lignes (pré-selectionnées) des commentaires (c'est pratique, non ?) Ctrl-E (again pour les décommenter). 6 - 0

NB : il s'agit du score Geany - GEdit, compté par mes soins.
Pour les "grands", je vous laisse débattre Vim vs Emacs. no souci.

---
@nohar : j'ai un programme A qui me calcule un gros tableau, je le sors dans une console, c'est un bloc, je copie-colle dans mon programme B qui sera le seul envoyé au juge.
Pour certains problèmes velus, comme celui là, il peut y avoir une partie hard codée, et une autre de traitement (sophistiquée ou non).

Question bonus pour VIM/emacs avec un langage verbeux mais très automatisable comme Java : est-ce qu'il y a des moyens de faire du refactoring ou de générer du code (getters, constructeurs, et plus si affinités) ?

Citation : SpaceFox

Question bonus pour VIM/emacs avec un langage verbeux mais très automatisable comme Java : est-ce qu'il y a des moyens de faire du refactoring ou de générer du code (getters, constructeurs, et plus si affinités) ?

Oui. Et même la Javadoc/Doxygen pré-remplie.

Citation

@nohar : j'ai un programme A qui me calcule un gros tableau, je le sors dans une console, c'est un bloc, je copie-colle dans mon programme B qui sera le seul envoyé au juge.

Mais qu'est-ce qui t'empêche de le remettre en forme dans le programme B ?
Y'a des éditeurs qui font ça automatiquement... Pas Geany ?

Citation

Autant vim/emacs pour un langage comme Python, je comprends, autant pour Java ça m'étonne déjà plus.

Bram l'utilise pour Java, donc oui c'est possible.

Ben écoute, programmer en JAVA sous vim, c'est pas super compliqué . Bon il a fallut que je comprenne deux trois petites choses (créations de packages, qu'es ce que c'était en réalité par exemple).

M'enfin, je ne suis pas super avancé en JAVA pour dire si je galère réellement avec vim, mais avec le peu que j'ai utilisé, vim ne me dérange absolument pas (juste eu besoin de redéfinir :make si je manipule un fichier java, ou même exécuté un build.sh si ce dernier est présent à la racine du projet).

Après, sans doute que eclipse semble plus approprié pour le java, mais vim ne me dérange pas pour le moment.

un peu HS mais il ne serait pas plus interessant, dans le cas de Java pour Android, d'utiliser eclipse avec un add on qui remplace l'editeur de texte par VIM ? je sais que ça existe, ce serais plutot le mieux non ? vim pour l'edition et la machinerie Eclipse pour toute la tool chain, emulateur & co

Ben franchement, je ne vois pas trop ce que me rapporterai en plus eclipse. Je suis très bien comme ceci, avec un build.sh qui compile le programme en l'envoie sur mon terminal connecter en usb.

Bon après je n'ai jamais testé eclipse réellement (peut être une fois très rapidement) mais bon, pour le moment, je ne me sens pas du tout limiter .

Citation : nohar

Mais qu'est-ce qui t'empêche de le remettre en forme dans le programme B ?
Y'a des éditeurs qui font ça automatiquement... Pas Geany ?

J'ai juste pas envie du tout.
30000 char ça fait combien de lignes pourries dans mon programme ???

Je préfère une seule ligne titanesque qui me bouffe mon écran visible.

Mais sinon, évidemment que Geany permet (comme GEdit) d'avoir les longues lignes splittées à la taille maxi demandée. Je sais que tu le sais ...

Alors, où GEdit marque-t-il un seul point face à Geany ?

Il semblerait que VIM s'automatise beaucoup plus que ce qu'on m'avait montré la dernière fois que j'ai eu droit à une démo. C'est plutôt cool.

Citation

J'ai juste pas envie du tout.
30000 char ça fait combien de lignes pourries dans mon programme ???

Attends, c'est juste pour une question de confort visuel que tu pourris l'input buffer de tous les softs qui vont ouvrir ton programme ?

Tout éditeur qui se respecte te permet nativement de masquer des lignes (le mot-clé est code folding), soit sémantiquement parce qu'il reconnait un bloc décrivant une fonction ou une classe, soit tout bêtement (c'est comme ça que je le fais en général parce que c'est plus souple), en plaçant des marqueurs avec commentaires du style # Déclarations {{{ avant et # }}} après la partie du fichier que tu veux masquer dans l'éditeur.

De cette manière, ton éditeur ne t'affiche qu'une ligne du style

+ Déclarations (36 folded lines)

... que tu peux "déplier" ou "replier" au besoin.

Citation : nohar

Citation

J'ai juste pas envie du tout.
30000 char ça fait combien de lignes pourries dans mon programme ???

Attends, c'est juste pour une question de confort visuel que tu pourris l'input buffer de tous les softs qui vont ouvrir ton programme ?

Tout éditeur qui se respecte te permet nativement de masquer des lignes (le mot-clé est code folding), soit sémantiquement parce qu'il reconnait un bloc décrivant une fonction ou une classe, soit tout bêtement (c'est comme ça que je le fais en général parce que c'est plus souple), en plaçant des marqueurs avec commentaires du style # Déclarations {{{ avant et # }}} après la partie du fichier que tu veux masquer dans l'éditeur.

De cette manière, ton éditeur ne t'affiche qu'une ligne du style

+ Déclarations (36 folded lines)

... que tu peux "déplier" ou "replier" au besoin.

Intéressant ton truc, c'est pas mal, mais avec Geany, il y a par défaut la possibilité de plier le code (les fonctions, les boucles, ...) ça c'est très bien.
C'est aussi chez GEdit, à ma connaissance.
Mais on peut pas plier une ligne très longue. (enfin, au moins Geany ne rame pas, alors que GEdit est plombé).

Mes programmes n'ont pas vocation à être ouverts pas d'autres, mais uniquement lancés par le juge en ligne, c'est pourquoi je dois tout mettre dans un seul fichier. Je concède que c'est mal de tout mettre dedans, et idem quand je code en C.

---

Peux-t-on s'accorder sur un point ?
Si on débute l'algorithmique ou un langage, n'est-il pas pertinent de commencer par faire une ou deux saisons de programmes mono-fichier, avant de passer à la modularité ?
Dans ce cas, un bon éditeur de texte me semble parfait.

Dans le cas de la modularité, je crois qu'il est utile de découvrir un vrai EDI.
Je dis ça sans savoir, car je pratique pas, et ne sais même pas faire.
Non ?
(Peut-on mettre Vim et Emacs dans la catégorie EDI ? je suis tenté de dire oui, mais je sais pas)

Citation : Francky_laH

Citation : nohar

Citation

J'ai juste pas envie du tout.
30000 char ça fait combien de lignes pourries dans mon programme ???

Attends, c'est juste pour une question de confort visuel que tu pourris l'input buffer de tous les softs qui vont ouvrir ton programme ?

Tout éditeur qui se respecte te permet nativement de masquer des lignes (le mot-clé est code folding), soit sémantiquement parce qu'il reconnait un bloc décrivant une fonction ou une classe, soit tout bêtement (c'est comme ça que je le fais en général parce que c'est plus souple), en plaçant des marqueurs avec commentaires du style # Déclarations {{{ avant et # }}} après la partie du fichier que tu veux masquer dans l'éditeur.

De cette manière, ton éditeur ne t'affiche qu'une ligne du style

+ Déclarations (36 folded lines)

... que tu peux "déplier" ou "replier" au besoin.

Intéressant ton truc, c'est pas mal, mais avec Geany, il y a par défaut la possibilité de plier le code (les fonctions, les boucles, ...) ça c'est très bien.
C'est aussi chez GEdit, à ma connaissance.
Mais on peut pas plier une ligne très longue. (enfin, au moins Geany ne rame pas, alors que GEdit est plombé).

L'idée c'est d'étaler ta ligne en plusieurs, et de plier tout le pâté.

Ton fichier va forcément être lu par un interpréteur Python, non ?

D'ailleurs, c'est un truc intéressant à tester : est-ce que ton script ne serait pas plus rapide si tu ne forces pas l'interpréteur à réallouer son buffer de lecture (parce que je doute très fort que le buffer dans lequel Python stocke ses lignes fasse 30Ko à la base !).

Citation

Peux-t-on s'accorder sur un point ?
Si on débute l'algorithmique ou un langage, n'est-il pas pertinent de commencer par faire une ou deux saisons de programmes mono-fichier, avant de passer à la modularité ?
Dans ce cas, un bon éditeur de texte me semble parfait.

Ouais, ça je suis d'accord.

Citation

Dans le cas de la modularité, je crois qu'il est utile de découvrir un vrai EDI.
Je dis ça sans savoir, car je pratique pas, et ne sais même pas faire.
Non ?
(Peut-on mettre Vim et Emacs dans la catégorie EDI ? je suis tenté de dire oui, mais je sais pas)

Là je suis pas forcément entièrement d'accord. Mais ça dépend de ce à quoi on aspire.

Je pense que l'EDI représente aussi un piège dans lequel il est facile de tomber. Je suis de ceux qui pensent que l'EDI masque trop de détails importants au départ. Il est fait pour simplifier le travail en automatisant les tâches répétitives (genre en C, compiler tout le projet avec un simple bouton), mais ce "masque" doit tomber quand même à un moment ou un autre. Il me semble important de voir relativement tôt comment se passe la compilation derrière ce bouton par exemple. Et ça, quand on compile une fois ou deux son projet à la main avec gcc en ligne de commande (exactement ce que fait l'EDI, en fait), on a plus l'impression de "toucher" les choses, et de les manipuler, ce qui aide à acquérir une certaine intuition du truc.

Bon, évidemment, ça ne sert pas à grand chose si le but c'est juste de bidouiller 2/3 programmes sans jamais avoir l'intention d'aller plus loin. Mais je pense que si on veut devenir bon, ça devient nécessaire de connaître ce genre de trucs périphériques, sans compter que les EDI sont aussi limités dans les possibilités (alors qu'un outil plus manuel comme CMake te permet d'avoir un contrôle très fin sur la génération du projet et même le packaging de l'application, tout en restant très simple à utiliser dans les cas de base).

En conclusion : je suis d'accord que ça dépend avant tout des aspirations des gens. Il n'est pas forcément utile de maîtriser et de fine-tuner son shell si on aspire juste à coder 2/3 scripts de temps en temps. Mais si on veut bosser sur des projets un tout petit peu ambitieux sous Linux (disons "qui sortent du cadre de ta machine en local"...), ou si on veut faire des trucs un petit peu chiadés, ça devient très vite un avantage de BIEN connaître son système (sans devenir un bète de sysadmin non plus, hein), ce que les EDI et les interfaces graphiques ne facilitent pas du tout ("Suffit de cliquer sur un bouton, pourquoi je me ferais chier ?"... jusqu'au jour où on a besoin de faire un peu plus que cliquer sur ce foutu bouton et que l'EDI ne fait plus les choses exactement comme on le voudrait).

Citation : nohar

Citation

Peux-t-on s'accorder sur un point ?
Si on débute l'algorithmique ou un langage, n'est-il pas pertinent de commencer par faire une ou deux saisons de programmes mono-fichier, avant de passer à la modularité ?
Dans ce cas, un bon éditeur de texte me semble parfait.

Ouais, ça je suis d'accord.

[...]

Je pense que l'EDI représente aussi un piège dans lequel il est facile de tomber. Je suis de ceux qui pensent que l'EDI masque trop de détails importants au départ.

[...]

Du coup ne pourrais t'on pas dire que pour commencer l'ideal est justement de ne pas toucher d'EDI ? tu utilise un editeur de texte, ton code est mono-fichier, et tu es obligé de faire les étapes de base à la main. Je pense qu'on conseil facilement a tord l'EDI aux débutant. Pour moi à la base les EDI c'est un truc de pro, quand justement tu maitrise suffisament les outils pour ce qu'il fait soit connu. On le voit sur les forum C/C++ ici : il y en a un paquet qui viennent avec une erreur de linkage a la con car ils n'ont pas compris qu'il fallait dire à l'IDE de linker la lib. Ou des gens devant compiler un projet sous linux pour la première fois de leur vie dont ils viennent de chopper les sources et qui comprennent pas qu'il n'y arrive pas avec un gcc main.c. Comment ça il faut lister tous les fichiers sources ? Oui il y a un MAKEFILE mais comme je ne sais pas ce que c'est j'ai ignoré.

Pour moi c'est comme tout. L'informatique est un outil. Et je pense qu'une des choses qui est importante est qu'il faut comprendre ce que fait notre outils et pourquoi avant de l'utiliser. C'est d'ailleurs un argument actuellement mit en avant pour ceux qui veulent que la prog soit enseigné à tous tot à l'école : l'informatique s'apprette à tout controler dans notre monde. Mais ce ne sont pas des boite magiques. Il est important que l'on comprenne ce qu'il se passe si on ne veux pas être controlé par les machines.

Bon j'ai un peu extrapolé là mais pour moi l'IDE ne devrais être utilisé qu'une fois que l'on maitrise la chaine de compilation à la main. ça nous eviterais déjà les questions "j'y comprend rien il y a trop d'options". A trop cacher la difficulté on empeche les gens de raisoner par eux même

<troll>IDE == Truc automatique qui bouffe de la ram là où on peut faire le même boulot sur notepad en manuel?</troll>

Bon, je troll un peu j'avoue. Mais perso je ne suis pas vraiment fan de ces outils (j'aime pas les boites noires). Donc je n'utilise que notepad++ et un peu code::blocks de temps en temps (suivant mon degré de fatigue.)
Cependant pour en revenir à python, bah étant habitué à np++ je tourne avec... et je teste via la console python (windowsien powa).

Ah et pour ce qui est de cette question :

Citation : Francky_laH

(Peut-on mettre Vim et Emacs dans la catégorie EDI ? je suis tenté de dire oui, mais je sais pas)

Non, Vim n'est vraiment qu'un éditeur (très paramétrable et pluginisable, certes) mais pas ce que j'appelle un EDI, puisque l'environnement en question que j'utilise est composé en gros, suivant les langages, de Vim + screen + gdb + gcc + cmake + python + shell + ... . <troll>Et Emacs est un OS...</troll>

Vu tout le bien que j'ai toujours entendu sur Vim, j'ai souvent eu l'envie de "m'y mettre". Mais rien à faire, j'en reste à :

• me déplacer avec les touches directionnelles et "goto début / fin"
• :w ; :wq et :q!
• dd plein de fois pour supprimer des lignes
• et deux trois trucs dans le genre, rien de plus.

Prenons un cas tout bête : je veux déplacer une quinzaine de lignes d'un bloc de code vers un autre. Sous l'éditeur que j'ai sous la main (sublime text 2) :
Sélectionner la zone voulue à la souris -> Ctrl-X -> cliquer là où on veut le coller -> Shift-Ctrl-V.
Sous vim ? Je dois m'amuser à compter le nombre de lignes ? C'est un truc que j'ai jamais trop saisi. Oui je sais que 'dd' est modifiable en 'dw' pour un mot, 'd5w' pour 5 mots... mais qui compte ça ? Ai-je loupé quelque chose ?

Bref du coup je m'en sers uniquement quand j'ai pas le choix, mais j'ai l'impression de passer à côté de quelque chose..