Après plusieurs années de développement et 6 betas, la nouvelle mouture de l'éditeur est enfin disponible en version stable.
Les principales améliorations sont :
- Correction orthographique pour 50 langues
- Complétion "intelligente" (Omni-complétion = complétion par contexte) pour : C, HTML, Ruby, Python, PHP...
- Onglets pouvant contenir plusieurs fenêtres chacun
- "Arbre d'annulation" (Undo branches) permettant d'éviter la perte de texte accidentelle
- Ajout de listes et de dictionnaires dans les scripts Vim (comme en Python)
- Profiling pour les scripts Vim
- Amélioration du support de l'unicode
- Mise en évidence de la ligne/colonne courante ainsi que des parenthèses/crochets/accolades correspondantes
- Support de la traduction pour les pages de manuel
- Grep interne fonctionnant sur toutes les plateformes permettant de chercher dans les fichiers compressés
- Parcours de répertoire à distance ainsi que des archives zip et tar
- Affichage des caractères multi-octet
Bram Moolenaar a récemment annoncé son embauche par Google, suite à laquelle il ne travaille plus sur Vim à plein temps. Rappelons que Vim est toujours un "charityware" : il est distribué sous une licence compatible GPL, cependant l'auteur encourage les dons à une association humanitaire (ICCF, en l'occurrence).
NdM: merci également à Axioplase et Merlin pour leur proposition de dépêche. Le changelog depuis la version 6.4 (dernière version stable de Vim) peut être obtenu en tapant ":help version7".
Les dictionnaires pour les différentes langues peuvent être obtenus automatiquement via ":set spellang=xx" (xx étant évidemment la langue souhaitée).
Enfin, pour avoir l'omni-complétion avec le C++ (et le Java dans une moindre mesure), il existe le plugin IComplete disponible à l'adresse : http://stud4.tuwien.ac.at/~e0125672/icomplete/
Aller plus loin
- Vim (27 clics)
- Annonce de la sortie (25 clics)
- Téléchargement (4 clics)
- Dictionnaires (3 clics)
# Allez...
Posté par Mithfindel (site web personnel) . Évalué à -1.
[] <----
[^] # Re: Allez...
Posté par Anonyme . Évalué à -7.
ln -s /usr/bin/ed /usr/bin/vim
[^] # Re: Allez... (bonne pratique de contributeurs)
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Au moins pas de soucis, le binaire le mieux classé par le packageur remplacera le moins bon.
Exemple :
/usr/bin/vi qui pointe sur vi-minimal, vi-improved sinon...
Enfin c'est une bonne pratique, ça dois marcher sur pas mal de distribution et ça évite de se retrouver avec un :
/usr/bin/vi -> rien du tout (en rouge)
Vala ;)
Quand a ed, c'est pas utilisé pour beaucoup de chose...
Selon urpmi j'ai jade* tex* kdevelop postfix linuxdoc-tools donc c'est pas très end-user comme logiciel (ed), le reste c'est très bien...
[^] # Re: Allez...
Posté par Mithfindel (site web personnel) . Évalué à 4.
[^] # Re: Allez...
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Édition de texte : ed
Il existe d'autres éditeurs de texte sous Unix comme vi et Emacs, mais ed est tout de même le plus simple et le plus intuitif.
# Traduction de la documentation de Vim en francais
Posté par Sarpedon . Évalué à 9.
http://vim.dindinx.net/index.php?p_menu=avancement
[^] # Re: Traduction de la documentation de Vim en francais
Posté par Toucouch (site web personnel) . Évalué à -2.
Je pense qu'il va y avoir pas mal de modifications dans le manuel de Vim 7, et donc pas mal de boulot de traduction en perspective: avis aux amateurs...
# Les paquets pour mandriva (cooker) ici :
Posté par Raphaël G. (site web personnel) . Évalué à 8.
http://rapsys.free.fr/mandriva/
Ceux qui les avaient utilisés, veillez simplement a remplacer les vieux paquets par cette version.
Pour ceux qui sont en stable un :
rpm --rebuild vim-7.0-1mdk.src.rpm
devrait suffire.
Ayant testé la rc2 j'ai pas vu de bug...
Pour la doc je ne l'ai pas incluse si elle n'est pas dans le tar.bz2 officiel, pour la release 2mdk (mais je vais attendre que ce soit finit et faire une titre relecture d'une partie pour aider pendant ce temps...)
Pour les nouveautés, il en manque une assez importante :
Le fait que les parenthèses/accolade/crochets soient mise en évidence...
Je vous raconte pas comme c'est pratiques que des :
if (fonction(...) == empty(fonction(fonction(...)))
Pour ce qui est de l'unicode, faut encore que je comprenne comment convertir le fichier en unicode a partir de d'iso8859-15 par exemple et ce sera super ;)
Avant je faisait un :%!recode iso8859-15..u8
mais depuis que le support de l'unicode est fait il fait la conversion a la volée et recode a rien a se mettre sous la dent (enfin si du utf-8) et du coup ça marche pas :'(
Si vous avez une idée, je suis preneur...
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par viridis (site web personnel) . Évalué à 1.
"Mise en évidence de la ligne/colonne courante ainsi que des parenthèses/crochets/accolades correspondantes"
...mais c'est vrai que j'ai pas été très clair sur ce point.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par herodiade . Évalué à 2.
Avant (vim6, peut etre meme avant) on avait déjà la possibilité de taper "%" lorsqu'on est sur une parenthese (ou accolade), ce qui déplace le curseur sur la parenthese corespondante.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par Florent Bayle (site web personnel) . Évalué à 4.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par Yann Forget . Évalué à -1.
sm pour sado-maso ?
Ok, bon -----> [].
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par Florent Bayle (site web personnel) . Évalué à 4.
Non, bien sûr, sm pour "showmatch".
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par Boa Treize (site web personnel) . Évalué à 7.
sm pour sado-maso ?
Comme le dit la documentation :
Note: For the use of the short form parental guidance is advised.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par alexissoft . Évalué à 3.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par 태 (site web personnel) . Évalué à 3.
[^] # Re: Les paquets pour mandriva (cooker) ici :
Posté par Boa Treize (site web personnel) . Évalué à 3.
# Petit bemol
Posté par cdvddt . Évalué à 8.
J'applaudis des deux mains pour les tabs et la completion des répertoires
a distance.
Seul déception : Le langage de script. Pourquoi continuer è développer
un langage abscon et mal foutu au lieu de privilegier l'intégration avec,
par exmeple, python.
Vim y gagnerait certaiment en communauté et en script.
Le langage de script courant est vraiment dégueu et mal fait. ça n'encourage pas à participer.
Bon voilà, c'était la petite note négative pour la form.
[^] # Re: Petit bemol
Posté par salvaire . Évalué à -3.
[^] # Re: Petit bemol
Posté par zerbro . Évalué à 3.
Il n'est certe pas super lisible (quoi que, avec une bonne indentation, et si on a bien réfléchi en amont a comment coder la chose... c'est pas pire que certains codes C/C++), mais qu'est ce qu'il est puissant comme langage fonctionel...
Ah oui, ca demande a savoir bien coder en récursif, et savoir ce que c'est qu'une fonction au sens mathématiques du terme :p
C'était pour marcher dedans, il parait que ca porte chance.
[^] # Re: Petit bemol
Posté par Philippe F (site web personnel) . Évalué à 7.
Ce sont des concepts qu'on est ravi d'utiliser quand on veut juste changer une option de config a la con. :-)
[^] # Re: Petit bemol
Posté par lasher . Évalué à 4.
Sinon, quand tu modifies un fichier de conf, mis à part ton .emacs, je n'en connais pas beaucoup qui ont besoin d'un dialecte LISP... :-)
[^] # Re: Petit bemol
Posté par Chaddaï Fouché . Évalué à 3.
--
Jedaï
[^] # Re: Petit bemol
Posté par david odin . Évalué à 10.
# Et les screenshots ?
Posté par olosta . Évalué à 1.
[^] # Re: Et les screenshots ?
Posté par Eric P. . Évalué à 9.
http://erixpage.free.fr/blog/index.php?2006/04/10/31-essayez(...)
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# ceci n'est pas un troll ...
Posté par rcmn . Évalué à 6.
J'essaye d'utiliser Emacs ou Vim depuis bien des années(je l'installe et le regarde lis la doc) mais mon temps est précieux et je fini toujours par me diriger vers un nano ou ee en console ou quanta/kate sur linux et (PSpad/notepad2) =>scite pour windows. Tous ces éditeurs ont un point commun =>rapidement facile a utiliser en ayant toutes les fonctions dont j'ai besoin.
En permanence je me demande quel est ce merveilleux monde que je n'ai pas le temps ou le courage de découvrir. Suis-je un esprit errant loin des lumières divine ??
Je sais que l'on choisi ces outils en fonction de ces besoins mais si je ne connais pas les possibilité de mon outils(sans l'utiliser) comment pourrais-je en avoir besoin.
Quels sont les fonctions que je n'ai pas avec les éditeurs que j'ai cite précédemment ;et qui justifierais ce long apprentissage ?
[^] # Re: ceci n'est pas un troll ...
Posté par Sarpedon . Évalué à 6.
LinuxJournal 2005 reader's choice
Favorite editor
1. Vim
2. Kate
3. Emacs
http://www.linuxjournal.com/article/8520
Et oui, procurer 80% des fonctionnalités vraiment agréables de vim ou d'emacs usées en pratique par les utilisateurs autres que les demi-dieux, le tout avec un temps d'apprentissage 10 fois plus court, c'est pas mal non ?
PS : oui, emacs fait email, web,... mais les applications KDE parmi lesquelles kate s'intègre parfaitement le font aussi mais beaucoup mieux. Pis, vim roxor quand même et mérite toujours cette première place.
[^] # Re: ceci n'est pas un troll ...
Posté par viridis (site web personnel) . Évalué à 8.
Sous vim, j'ai les différents modes (visualisation, edition...) et la façon d'utiliser telle ou telle fonctionnalité me plait.
En gros, je préfère passer en mode commande puis en taper une (je tape tombe des caractères à la suite) plutôt que d'utiliser un racourcis agrémenté des touches Ctrl et Alt (plusieurs touches en même temps). Après le résultat est le même, c'est juste le moyen de procéder qui diffère.
C'est comme les personnes qui lancent toutes leurs applications depuis un terminal et ceux qui utilisent un desktop manager pour avoir des menus.
PS: Je sais qu'on peut taper les noms de commande dans emacs et utiliser des mappings dans vim...
[^] # Re: ceci n'est pas un troll ...
Posté par xavier . Évalué à 8.
sinon bien qu'utilisant vim comme emacs pour des taches differentes, ma preference va le plus souvent a vim (y compris pour des sexp paradoxalement) par ce que je le trouve plus #1=(facile a utiliser rapidement . #1#) ;)
[^] # Re: ceci n'est pas un troll ...
Posté par Sebastien Binet . Évalué à 2.
Donc: hop, dans la course.
(Oui je sais, on peut faire ca avec les autres, hein)
[^] # Re: ceci n'est pas un troll ...
Posté par Boa Treize (site web personnel) . Évalué à 10.
Ouais, mais parmi les 20% qui manquent y'en a deux totalement vitales pour beaucoup de gens :
* Vi(m) est présent ou trivialement installable sur toutes les machines du monde
* Vi(m) fonctionne avec tous les types d'accès possibles (notamment en mode texte, en accès SSH)
[^] # Re: ceci n'est pas un troll ...
Posté par fabien . Évalué à 5.
en voilà une nouveauté...
moi vim c'est parceque ca marche dans un ssh, ou quand je susi loggé en ligne de commande (pas de X lancé)
[^] # Re: ceci n'est pas un troll ...
Posté par Thomas Douillard . Évalué à -3.
[^] # Re: ceci n'est pas un troll ...
Posté par xumelc . Évalué à -2.
[^] # Re: ceci n'est pas un troll ...
Posté par Aurélien Bompard (site web personnel) . Évalué à 0.
Et tout est transparent, et pas besoin de X sur le serveur.
[^] # Re: ceci n'est pas un troll ...
Posté par Sarpedon . Évalué à 3.
http://vim.dindinx.net/traduit/html/pi_netrw.txt.php
+==============================+==============================+============+
| La lecture avec | L'écriture avec | utilise |
+==============================+==============================+============+
| :Nread rcp://hôte/chemin | :Nwrite rcp://hôte/chemin | rcp |
| :Nread ftp://hôte/chemin | :Nwrite ftp://hôte/chemin | ftp+.netrc|
| scp://[user@]hôte/chemin | scp://[user@]hôte/chemin | scp |
| :Nread dav://hôte/chemin | :Nwrite dav://hôte/chemin | cadaver |
| :Nread rsync://hôte/chemin | :Nwrite rsync://hôte/chemin | rsync |
+=============================+==============================+============+
Mais toutes les applications KDE pareil, donc 2-1 pour kate.
[^] # Re: ceci n'est pas un troll ...
Posté par Christophe Morvan (site web personnel) . Évalué à 2.
?
Les autres appli de kde le font => point pour kate ?
Et puis il faut m'expliquer comment ça se passe lorsque tu fais un rebond (par exemple ssh sur une passerelle puis ssh sur un autre machine ?)
Ou encore quand tu veux changer d'utilisateur par "su" plutôt que de permettre ssh pour tous les utilisateurs (par exemple root).
Pour ça rien ne remplace vi(m) ou (x)emacs qui marchent tous très bien sans x dans un terminal.
Résultat 3-1 pour vim ! ;o)
(je ne parle même pas des combinaisons de touches d'emacs qui stimulent la dextérité manuelle)
[^] # Re: ceci n'est pas un troll ...
Posté par Erwan . Évalué à 10.
Ce sont des petits details, comme "o" pour commencer une nouvelle ligne, "yw" pour copier un mot, ou "dw" pour supprimer un mot, "y4y" pour copier 4 lignes ou "d4d" pour supprimer 4 lignes qui font toutes la difference. Bien sur tu appuyer 10 fois sur "delete", ou selectionner a la souris, mais c'est moins efficace.
[^] # Re: ceci n'est pas un troll ...
Posté par reno . Évalué à 2.
Avec vi t'es un peu trop obligé de compter le nombre de lignes, c'est ce que je lui reproche.
On peut peut-être dire, "marquer ici", aller la ou on veut et faire "copier/couper" depuis la marque, mais je ne sais pas faire..
Ou plus faire, le probleme avec toutes ces options exotiques, c'est de les retenir..
[^] # Re: ceci est un troll ...
Posté par 태 (site web personnel) . Évalué à 3.
Ensuite, pour sélectionner un bloc tu as aussi les possibilités liées à la teneur du bloc (genre si tu veux effacer tout le paragraphe courant : dap ; pour un mot daw ; pour une "phrase" das ; etc...)
Et surtout, tu n'es pas obligé de tout retenir éternellement, la commande help est très utile (surtout avec la complétion).
[^] # Re: ceci n'est pas un troll ...
Posté par Erwan . Évalué à 4.
* v
* Aller ou on veut (dans gvim la partie selectionnee apparait)
* Quand on est ou on veut "y" pour copier, "d" pour supprimer
Et bien sur, dans gvim toujours, en mode edition le copier/coller a la souris marche (bouton du milieu pour coller.
Ou plus faire, le probleme avec toutes ces options exotiques, c'est de les retenir..
C'est pour ca que ca depend si tu utilises souvent ton editeur ou pas. Si tu l'utilises souvent, alors tu n'auras pas de probleme pour retenir les commandes, si tu ne t'en sers pas souvent mieux vaut rester a gedit.
[^] # Re: ceci n'est pas un troll ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Lorsque tu utilises Vim tous les jours, tu n'oublie pas les fonctionnalitées ;)
[^] # Re: ceci n'est pas un troll ...
Posté par Philippe F (site web personnel) . Évalué à 4.
- un mode ou le texte que tu tapes est insere, comme sur Kate ou les autres editeurs classiques
- un mode ou chaque touche correspond en fait a une action, que tu lancerais sur les autres editeurs via des combinaisons de Control ou ALT.
Ce second mode permet d'effectuer des actions complexes en laissant tes doigts a des emplacements faciles a joindre sur le clavier. D'une part, c'est moins fatiguant pour les mains, d'autre part, c'est beaucoup plus rapide.
Exemple, tu veux faire un copier/ colle :
- Kate version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste
- Kate version clavier : tu selectionnes le texte, tu fais Control-C, tu scrolles ton texte avec Page-Down et Cursor-Down, tu fais Control-V
- Vi version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste (a noter que c'est la meme chose que Kate version souris)
- Vi version clavier : tu demarra ta selection de texte avec V. Tu deplace ton curseur avec la touche kjhl pour contenir toutes les lignes que tu veux selectionner. Tu tapes y pour faire la copie. Tu te deplace a coup de page-up ou page-down (j'ai jamais pu me rappeler le racourci pour les sauts de pages), tu positionnes ton curseur avec les touches khjl et tu tapes P.
Si on compare kate et vi au clavier, on pourrait imaginer la suite de touches suivantes :
[Down]
[Down]
Control-[Right]
Control-[Right]
[Shift appuye]
[Down]
[Down]
Control-C
[Page-Down]
[Page-Down]
[Down]
[Down]
Control-V
et
j
j
w
w
v
j
j
y
[Page-Down]
[Page-Down]
j
j
p
Tu notes que les touches vi sont plus faciles a taper. A noter aussi que vi est relativement compatible avec un mode d'edition a la kate, de sorte qu'on peut envisager un apprentissage plus lent des foncitonnliates specifiques vi (par exemple, se deplacer au curseur plutot qu'avec jkhl).
[^] # Re: ceci n'est pas un troll ...
Posté par beagf (site web personnel) . Évalué à 2.
J'ai commencer à utiliser vi il y a 6 ans car, contrairement à emacs, il fonctionne parfaitement à travers une connexion ssh. Et les débuts on étés très difficile à cause de ces deux modes justement. Le cas typique : je suis en train d'éditer un fichier, je le sauvegarde avant d'aller vérifier un truc dans une autre fenêtre, quand je reviens je continu de modifier mon fichier et là, c'est le drame... je m'apperçoit au bout de quelques touches que j'ai oublier de repasser en mode édition et que je viens de foutre en l'air une partie de mon fichier.
En général, à ce moment là je peste contre vi en faisant des undo pour retrouver mon fichier tel qu'il était avant.
Le pire c'est sous X quand tu colle un bloc de données sans passer en mode édition et qu'il traite les caractères coller comme étant des commandes.
Il faut un sacré bout de temps pour s'habituer et comprendre toute la puissance qu'offre ces deux modes.
Pour moi, l'apprentissage à été lpus long que avec n'importe quel autre éditeur, mais je ne le regrette pas. J'ai même abandonné mon emacs, principalement pour la différence en temps de lancement et pour l'utilisation à travers ssh.
[^] # Re: ceci n'est pas un troll ...
Posté par Xavier Teyssier (site web personnel) . Évalué à 5.
[^] # Re: ceci n'est pas un troll ...
Posté par beagf (site web personnel) . Évalué à 5.
Le deuxieme probleme etait des bugs d'affichage, que je n'ai jamais pus resoudre a l'epoque, principalement avec les barres d'emacs qui s'affichait n'importe ou des que je splitait une fenetre, probleme que je n'avais plus avec vi.
Je ne dit pas que c'est toujours le cas, il y a pas mal de temps que je n'ai pas eu a utiliser emacs a travers un ssh. J'apprecie beaucoup vi depuis que j'ai appris a bien m'en servir.
Pour une utilisation locale la seule chose que je reproche a emacs, c'est ca lourdeur. Pour une utilisation distante, vu la connexion que j'ai maintenant et si il n'y a plus de probleme d'affichage, je n'ai plus rien a ajouter.
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . Évalué à 3.
Dès lors vim affichera le mode courant ("-- INSERT --" ou "-- VISUAL --") en dessous de la statusline.
[^] # Re: ceci n'est pas un troll ...
Posté par beagf (site web personnel) . Évalué à 1.
Maintenant je n'ai plus besoin de regarder le clavier, mais en general c'est pas pour ca que je regarde beaucoup plus mon ecran... (par contre j'ai appris a verifier le mode dans lequels je suis et a le memoriser quand j'ai peut de fenetre actives)
[^] # Re: ceci n'est pas un troll ...
Posté par MetalX . Évalué à 2.
Je ne peux pas croire que ça ne se fait pas, ou que personne n'y a pensé, mais je n'ai rien trouvé à ce sujet...
[^] # Re: ceci n'est pas un troll ...
Posté par gpe . Évalué à 2.
[^] # Re: ceci n'est pas un troll ...
Posté par Bruno Michel (site web personnel) . Évalué à 3.
au InsertEnter * :colo darkblue
au InsertLeave * :colo default
Pour juste changer la couleur d'arrière-plan, tu peux utiliser la commande :hi :
:hi Normal ctermbg=green guibg=green
Bon, ok, le vert, c'est pas forcément ce qu'il y a de mieux, mais c'était juste pour donner l'idée.
[^] # Re: ceci n'est pas un troll ...
Posté par Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . Évalué à 5.
C'est Ctrl-f et Ctrl-b.
Ton exemple représente un des pires cas pour vim concernant le nombre de touches à frapper.
Avec vim il y a des raccourcis pour les déplacements (ou selections ou deletions) les plus courants, comme { et } (parragraphe précédent et suivant), ou gg (aller en haut de fichier) et G (en bas de fichier), $ et 0 (fin / début de ligne), ou encore /motclef (pour aller directement à la place prochaine occurence de "motclef"), 5k (5 lignes plus haut), 8j (8 lignes plus bas), 4w (4 mots plus loins), 3b (3 mots avant) etc.
Bref, de quoi amplement réduire le nombre de Ctrl-F et autres j, k, l et h et souvent éviter le détour par le mode visuel.
Exemple, si on reprend ton exemple en considérant qu'on veut copier le paragraphe suivant à la fin du fichier, ça donne 5 fappes seulement:
} y # copier le paragraphe suivant
G # aller à la fin du fichier
p # coller
Ou bien copier la ligne courante et la coller deux paragraphes plus bas:
yy # copier la ligne courante, dd pour couper la ligne courante
}} # avancer le curseur de deux paragraphes
p # coller
De même les trucs comme jjjjj (avancer de 5 lignes) peuvent être condensés en deux frappes clavier: 5j.
Au passage, le coté très "automatique" de ces raccourcis (par opposition à ceux qui demandent un controle visuel, comme le saut d'écran ou le scroll à la souris) évite d'avoir à regarder son écran ou d'attendre d'avoir repéré le texte / l'emplacement pour passer à l'opération suivante.
On peut donc enchainer la série de raccourcis à la vitesse de la frappe, et ça, c'est un sacré accélération.
[^] # Re: ceci n'est pas un troll ...
Posté par Philippe F (site web personnel) . Évalué à 3.
Pour mon cas particulier, aller cherche l'accolade, c'est un shift plus la touche a cote de (je suis en clavier americain), ce qui veut dire deux utilisations du petit doigt droit et gauche. C'est un mouvement plutot difficile et fatiguant, ce qui fait que je ne l'utilise pas souvent.
Pour les jjjjj, pour moi, c'est plus rapide de les taper que de compter le nombre de lignes a l'ecran, de taper le nombre puis de taper j.
[^] # Re: ceci n'est pas un troll ...
Posté par jerome (site web personnel) . Évalué à 3.
Et bien, il y a beaucoup et en même temps peu de choses que tu manques. Tout celà dépend tellement du langage que tu utilises, de tes habitudes d'édition, que finalement si tu est heureux avec kate ou scite (qui sont d'après des sources fiables d'excellents éditeurs), c'est bien comme ça.
Bon, maintenant, si tu veux savoir ce qu'on aime généralement bien dans vim, au hasard :
* l'utiliser intégralement au clavier (et vite, c'est fait pour ça)
* la facilité de navigation en utilisant diverses touches de raccourcis pour accèder à la parenthèse qui va bien, à la déclaration d'une fonction/variable, au prochain bloc, etc (%, [] {} etc)
* réaliser des opérations diverses sur tout ou partie du buffer (bloc visuel, :g/pattern/opération, etc)
* utiliser des programmes externes, unix, sur le buffer courant :!programme
* l'utiliser dans screen/ssh à distance à partir de n'importe quel OS vers n'importe quel autre (sous entendu propre, mais même pas forcément)
* la disponibilité de scripts qui font tout ou presque (par exemple pour le xml au hasard)
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . Évalué à 5.
* le caractère universel : pas besoin d'apprendre un nouvel éditeur lorsqu'on change de langage de prog, de type d'utilisation (bloc-note, prog, admin et edition de fichiers de confs, webdesign, écriture de mail/news...), de système d'exploitation (que ce soit pour l'édition en local ou distance par ssh, graphique ou en console, sous unix ou pas). Bref, l'apprentissage de vi(m) est rentabilisé dans toutes les situations d'édition de texte.
* sa présence garantie sur quasi tout les unix modernes (sinon un vim, au moins un vi) ce qui fait qu'on n'est pas perdu, par exemple, en situation d'urgence / déplantage d'un systeme (n'importe qui devant maintenir une machine unix, fut-ce son poste sous linux, devrai de toutes façons apprendre les bases de vi pour déplanter son ordi en mode single-user et sans x11 ou via une disquette de secours).
Nombres d'éditeurs n'offrent pas la complétion et/ou la colorisation syntaxique dès qu'on n'utilise plus le (ou les 2 ou 3) language de prog pour lequel il sont prévus, ou ne sont pas utilisables par ssh / en console, ou ne marchent pas sous windows, ou ne s'intégrent pas avec des clients mail, ou sont payants (donc on ne les installe pas sur toutes les machines qu'on utilise) etc.
Ce qui fait qu'au moindre changement dans ses pratiques informatiques, il faut réapprendre les raccourcis qui permettent d'etre efficaces sur un autre outil. Pas avec vim (ni emacs d'ailleur).
[^] # Re: ceci n'est pas un troll ...
Posté par Alexandre Beraud . Évalué à 3.
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . Évalué à 3.
[^] # Re: ceci n'est pas un troll ...
Posté par Pooly (site web personnel) . Évalué à 3.
Justement en apprenant 2-3 trucs sous Vim, tu passes moins de temps par la suite pour l'édition. En peu de temps, c'est rentabiliser. Il faut voir sur le long terme !
[^] # Re: ceci n'est pas un troll ...
Posté par Touns . Évalué à 3.
Disons que c'est un peu comme l'ascention dans Stargate... le chemin est long et dur, mais ça en vaut la peine. Tu rejoindra les dieux... reste à savoir si ce ne sont pas de faux dieux!
[^] # Re: ceci n'est pas un troll ...
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
[^] # Re: ceci n'est pas un troll ...
Posté par GhZaaark3 . Évalué à 1.
Mais moi, l'apprentissage de vi/vim n'a pas dérangé car au final ça été vraiment payant. Ces modes sont super ingénieux.
Néamoins j'avoue que c'est inattendu comme approche, alors ça effraye peut-être mais on est seulement effrayé des choses qu'on ne connait pas. Tant pis pour ceux dont la curiosité ne dépasse pas celle d'un poireau ou qui pensent que tout est acquis à l'avance.
Donne toi un peu de temps, le didacticiel - vimtutor - ne prend que 30min.
Qu'est-c'donc 30min sur les centaines de minutes que tu gagneras à utiliser vIM?
Avantage: ben déjà que tu sois sous X ou Console, en local ou distant, tu as ce puissant outil à ta portée, à sa tu ajoutes ses inombrables qualités dont l'ergonomie (et oui!) et t'as plus à te poser de question.
Maintenant, si tu es satisfait avec ton editeur, qu'il réponde à toutes tes attentes dont visiblement celui d'être rapidement - tout est relatif - assimilable, pourquoi changer? t'as peur d'être "différent"? d'assumer tes choix? héhé
C'est mal penser que de se demander pourquoi cet engouement si tu ne te donnes pas la peine de l'essayer. Autant ne pas t'inquéter de ce que pensent les gens.
Personnellement, ça me saoule d'entendre chaque fois la même rengaine: "rapidité de prise en main". Ça n'est pas un argument désicif, voir un arguement tout court à mes yeux :) Ça n'annonce rien de la puissance d'un logiciel.
Ce n'est pas être maso, mais j'aime faire l'effort de comprendre les choses et de me faire mon opinion que je pourrais confronter à d'autres.
Et puis bon le résultat est là, on ne peut que se féliciter et féliciter le concepteur de ce formidable outil.
Bref, ne vous fiez pas aux apparences, approfondissez.
# Gvim (vim-x11)
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Actuellement, je n'utilise que rarement vi en mode console, j'utilise préférentiellement gvim en mode graphique. Il permet d'utiliser la souris de façon efficace et c'est parfois bien commode.
Depuis quelques temps, après la commande ":" qui positionne le curseur en bas de l'écran, on peut rappeler et éditer les commandes précédentes en utilisant les flèches comme avec bash. Dans le cas de commandes complexes, c'est un confort très appréciable.
[^] # Re: Gvim (vim-x11)
Posté par 태 (site web personnel) . Évalué à 2.
Bref vim et gvim apportent des fonctions dont vi n'a même jamais révé.
Je n'ai pas encore essayé vim7, mais il semble résoudre un des gros soucis que j'avais avec les précédentes versions : l'intégration d'un correcteur orthographique. Par contre, je suis assez déçu que ce soit un nouveau format et pas simplement une utilisation intelligente des aspell,ispell,myspell,cocoaspell (à la façon du script vimspell mais celui-ci était trop lent et désagréable au changement de langue à mon gout)...
[^] # Re: Gvim (vim-x11)
Posté par herodiade . Évalué à 2.
Je risque de te décevoir mais malheureusement ce nouvel outil de vérification d'ortographe est très ... hum, sommaire (pas vraiment contextuelle, pas de prise en compte de la sytaxe, conjugaison parfois approx., et chiant avec lorsqu'on utilise des mots informatiques, souvent anglais, dans du texte français, se vautre souvent lors de la vérification de texte dans du code html/c/python ...) :(
# Nedit ?
Posté par Alexandre Beraud . Évalué à 3.
[^] # Re: Nedit ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Je pense qu'en fait pour les gens qui editent vraiment _beaucoup_, un gain de productivite meme leger represente un confort important, et que c'est ce qui les conduits a des editeurs comme vim ou emacs, qu'ils defendent avec ardeur.
[^] # Re: Nedit ?
Posté par herodiade . Évalué à 1.
D'autant qu'on peut maintenant utiliser vim en remplacement de l'éditeur d'Eclipse (et de celui de VisualStudio, et de NetBeans, ... universel je vous dit! !) ;)
http://vimplugin.sourceforge.net/
ou
http://eclim.sourceforge.net/
[^] # Re: Nedit ?
Posté par Joël SCHAAL . Évalué à 2.
* Vim démarre en une seconde (et encore...) tandis qu'Eclipse en plusieurs dizaines de secondes, voire même quelques minutes
* Vim prends quelques Ko de mémoire tandis qu'Eclipse peut atteindre les centaines de mega (situation courante au boulot : 250 Mo)
* Eclipse intègre des plugins relativement différents de Vim : ils sont beaucoups plus graphiques (GEF) et sont beaucoup plus orientés développement (JDT, PDE, ...)
* La présentation des données n'est pas du tout la même dans Eclipse : notion de perspectives, d'arbres de visualisation de structure, liste des erreurs/warnings/todos intégrés directement dans l'editeur,...
* La manipulation des données (dans le cas d'une utilisation de développement d'Eclipse) n'est pas non plus la même : possibilité de refactoring assez puissante, gestion d'un historique local par fonction, organisation automatique d'imports, génération de code template (snippets), génération de méthode (getter/setter, override/implement,...), visualisation directe des héritages (notamment des fonctions) et navigation pratique dans le code des différentes classes (un CTRL-Clic sur le nom d'une fonction/d'une classe/d'un attribut permet de se déplacer vers sa déclaration, quelle que soit la classe qui la définit)
* L'intégration avec les gestion de source n'est, a mon avis, pas aussi poussée dans Vim (je ne connais pas trop, merci de confirmer|infirmer)
Je pourrais continuer encore longtemps, et je pense avoir oublié pas mal de points plus importants que ceux listés ci-dessus, mais en gros, on voit assez bien que Vim et Eclipse ne sont pas destinés au même usage : Pour des projets de développement de grosse taille, je pense qu'Eclipse serait un meilleur choix, tandis que pour les modifications plus ponctuelles je choisirais davantage vim.
Joel.
[^] # Re: Nedit ?
Posté par herodiade . Évalué à 2.
Heu, oui, mais je doit préciser : c'était surtout une blague (les contrastes, toussa ...) !!
Évidement je ne donnerais jamais mon baril de vim contre deux barils de kate, nedit et eclipse ! ;)
La présentation des données n'est pas du tout la même dans Eclipse [...]
En fait, pour la plupart, des choses qui sont disponibles dans vim (nativement, comme la gestion des erreurs/warnings, ou par plugins, comme pour la navigation dans les classes et fonctions ou les templates et la génération des accesseurs). Par contre, c'est vrai que les fonctions de refactoring Java sont absentes de vim.
L'intégration avec les gestion de source n'est, a mon avis, pas aussi poussée dans Vim (je ne connais pas trop, merci de confirmer|infirmer)
Je ne suis pas sûr que tu parle des logiciel de gestion de révisions (type rcs, cvs, svn etc.) mais si c'est ça, la situation de vim et eclipse sont en tout point comparables: c'est totalement géré, via des plugins.
Pour des projets de développement de grosse taille, je pense qu'Eclipse serait un meilleur choix, tandis que pour les modifications plus ponctuelles je choisirais davantage vim
Et bien voilà le sens des plugins cités plus haut: désormais, tu n'es plus obligé de choisir ;)
Sinon, blague à part, je dirais plutôt: pour travailler sur du Java, Eclipse est excellent, pour le reste vim est une valeur sûre (pour avoir essayé les plugins pour php, python et C sous Eclipse, je peut t'assurer que c'est pas aussi bien géré que java, de loin ...).
[^] # Re: Nedit ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
J'irais pas dire que c'est courant, mais faut pas non plus dire que Vim se contente de quelques kilos :
xate@Corindon:/tmp$ top -n1 |grep vi
25565 xate 18 0 293m 284m 2096 R 5.1 56.5 0:52.87 vi
Tout dépend de ce qu'on fait avec Vi !
[^] # Re: Nedit ?
Posté par Antoine . Évalué à 1.
Kate marche très bien sous Gnome.
[^] # Re: Nedit ?
Posté par Spyhawk . Évalué à 2.
[^] # Re: Nedit ?
Posté par Kibos . Évalué à 1.
[^] # Re: Nedit ?
Posté par 태 (site web personnel) . Évalué à 6.
(qa pour enregistrer en live la macro nommée a, @a pour la replayer)
[^] # Re: Nedit ?
Posté par Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Nedit ?
Posté par Merlin (site web personnel) . Évalué à 2.
pour ceux qui ne sont pas au courant, ca permet de repeter la derniere commande utilisee (sauf commande de deplacement)
depuis que je connais ca, je ne peux plus m'en passer...
[^] # Re: Nedit ?
Posté par Boa Treize (site web personnel) . Évalué à 2.
Y'a la touche * aussi, pour lancer une recherche sur le mot qui est sous le curseur. Avec la touche n pour passer au résultat suivant, c'est très rapide. :)
[^] # Re: Nedit ?
Posté par Kibos . Évalué à 2.
[^] # Re: Nedit ?
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
C-x ( => commencer une macro
C-x ) => terminer une macro
C-x e => rejouer la dernière macro.
Bon, pour la killer-feature exclusive, c'est raté je crois ;-).
# des questions
Posté par cbon linux . Évalué à 1.
Je ne suis pas un habitué de vim mais plutot de vi et emacs.
Quelques questions :
- 50 langues pour la correction orthographique ? Pourquoi pas 150 ? Et quel interet si on code seulement ?
- quel est le langage des script vim ? et que fait-on avec ?
- quel interet de chercher dans les fichiers compressés ?
Au fait, y a vi et emacs qui sont bien, pourquoi un vim ?
Vous connaissez des éditeurs de code ou de texte encore plus simples à utiliser que vi ou emacs ?
Merci.
[^] # Re: des questions
Posté par 태 (site web personnel) . Évalué à 2.
Tu peux écrire des scripts dans le langage spécial vim, ou en python ou en perl ou en ruby (si vim est compilé avec le support du langage)
Ce qu'on fait avec est varié : ça va du petit script qui permet de lancer le visualiseur postscript au bon endroit au bidule qui permet de faire de l'irc dans vim en passant par des plugins avancés d'utilisation de ctags. Tu peux aller voir sur vim.org pour une liste des scripts existant.
> quel interet de chercher dans les fichiers compressés ?
tu es dans vim, tu fais :e README.gz et tu peux lire le README sans avoir à le décompresser avant, et sans en changer le timestamp.
> Au fait, y a vi et emacs qui sont bien, pourquoi un vim ?
vi est très sommaire : pas de coloration syntaxique, pas de mode visuel, pas de correction orthographique, pas de scripts en perl... vim apporte beaucoup de fonctions supplémentaires tout en restant compatible avec vi.
> Vous connaissez des éditeurs de code ou de texte encore plus simples à utiliser que vi ou emacs ?
nano est plus accessible, et petit et sympathique.
[^] # Re: des questions
Posté par herodiade . Évalué à 3.
Comme j'ai dit plus haut, vim utilise les dictionnaires de langues d'OpenOffice.org. Il supporte donc autant de langues qu'OOo (soit: autant qu'il y a eu des volontaires pour écrire des dictionnaires).
Concernant l'intéret du correcteur , il est surtout flagrant pour les utilisations généralistes de vim (par exemple pour l'édition d'emails en backend de mutt). Mais même lorsqu'on l'utilise pour coder, c'est parfois utile de pouvoir vérifier l'orthographe des textes des messages dans le code (ou dans les fichiers gettext etc).
- quel est le langage des script vim ? et que fait-on avec ?
Le language de script natif, toujours inclus, est le viml (un ml sur mesure).
Les languages Python, Perl, Ruby ou TCL sont aussi supportés (mais peuvent être activés ou pas, selon les options de compilation de vim).
Ce qu'on fait avec ? c'est très varié, jette un oeil ici : http://www.vim.org/scripts/
- quel interet de chercher dans les fichiers compressés ?
Vim permet de travailler de façon transparente avec les fichiers compréssés (.gz, .zip, .bz2), et même les archives (.tar, .tar.gz, .tgz, .tar.bz2).
On peut les éditer directement, sans avoir à la décomprésser (vim foo.tar.gz).
Dans le cas des archives, on les parcoure comme s'il s'agissait de simples répertoires, et on peut ouvrir, éditer les fichiers qu'elles contiennent ...
C'est pourquoi la possibilité de chercher / grepper dans les fichiers compréssés est pertinente ici.
[^] # Re: des questions
Posté par wilk . Évalué à 1.
[^] # Re: des questions
Posté par FueL . Évalué à -1.
Oui pourquoi autant de langues, après tout à l'étranger ils parlent étranger alors on en a pas besoin...
(toute ressemblance avec le site cretin.fr serait fortuite) :]
# Je me dévoue
Posté par Zakath (site web personnel) . Évalué à 6.
M'enfin bon, il faut bien que quelqu'un s'en occupe, donc :
vi ça pue, emacs rulez
Disclaimer: ce message ne reflète en rien les opinions de son auteur.
[^] # Re: Je me dévoue
Posté par Spack . Évalué à 2.
Vi peut être par contre Vim rulez...
[^] # Re: Je me dévoue
Posté par sbugsin . Évalué à -1.
[^] # Re: Je me dévoue
Posté par FueL . Évalué à -2.
# Dictionnaire et undo tree ?
Posté par FueL . Évalué à 1.
Qu'est ce que ça change par rapport aux outils en ligne de commande style spell ? surtt qu'on pouvait l'appeler depuis Vim.
Quelqu'un a-t-il un petit mapping sympa sous Win32 pour allouer à la touche "clique-droit" de windows, l'appel aux suggestions orthographiques ?
Et surtout niveau nouveauté du undo tree, comment navigue-t-on dans cet arbre justement ? Un exemple où cette nouvelle fonction permet de récupérer une modif que l'ancien Vim ne pouvait pas ?
Merci pour vos réponses.
[^] # Re: Dictionnaire et undo tree ?
Posté par paco81 . Évalué à 1.
>français, si oui ça donne quoi ?
>Qu'est ce que ça change par rapport aux outils en ligne de commande style spell ?
>surtt qu'on pouvait l'appeler depuis Vim.
Pour ce que j'ai testé, ça marche bien ! ^_^
Le menu popup avec les suggestions est bien foutu, et marche aussi en mode console (en mode insertion, ctrl-x_s). Et le z= en mode normal est aussi bien pratique, tu peux faire le choix à la souris, même en mode console.
Pour les différences avec le plugin des vim précédents, il me semble que c'est plus rapide, mais j'ai très peu testé le plugin. Sinon, tu ne dépend plus d'un programme externe (ce n'était peut-être pas possible de faire marcher le plugin sous windows par ex. (?)).
>Quelqu'un a-t-il un petit mapping sympa sous Win32 pour allouer à la touche
>"clique-droit" de windows, l'appel aux suggestions orthographiques ?
Avec gvim sous linux, le clic droit marche out-of-the-box... J'ai pas testé sous windows.
>Et surtout niveau nouveauté du undo tree, comment navigue-t-on dans cet arbre
>justement ? Un exemple où cette nouvelle fonction permet de récupérer une modif
>que l'ancien Vim ne pouvait pas ?
Il y a plusieurs moyens de naviguer dans l'arbre (:help undo-tree pour en savoir plus).
Un moyen très pratique : ":earlier 1h" ou ":later 5m"
Un exemple où ça peut servir : tu fais une grosse série d'annulations (du style 1000u). Si tu recommences faire une modification, tout ce que tu as annulé à l'instant sera perdu (avec vim <7.0). Mais là, un :earlier 1m et c'est récupéré !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.