Sortie de Vim 7

Posté par (page perso) . Modéré par Benoît Sibaud.
Tags :
0
8
mai
2006
Bureautique
Bram Moolenaar l'a annoncé sur la liste de diffusion : "Vim 7 is ready!"

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

  • # Allez...

    Posté par (page perso) . Évalué à -1.

    ED is the standard editor.

    [] <----
    • [^] # Re: Allez...

      Posté par . Évalué à -7.

      ok
      ln -s /usr/bin/ed /usr/bin/vim
      • [^] # Re: Allez... (bonne pratique de contributeurs)

        Posté par (page perso) . Évalué à 2.

        Quand vous utilisez ce genre de truc, mieux vaut utiliser du update-alternative.

        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 (page perso) . Évalué à 4.

      Rhooo mais y'a même pas moyen de faire de l'humour sans se faire moinser ici (c.f http://www.gnu.org/fun/jokes/ed.msg.html ). 'Fin y'en a quand même qui ne connaissent pas leurs classiques.
      • [^] # Re: Allez...

        Posté par (page perso) . Évalué à 5.

        Lu dans des vrais transparents de vrai cours pour vrais débutants sous Unix, donné à la rentrée 2005 (adaptation libre, de mémoire, mais c'est prèsque ça mot à mot) :

        É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 . Évalué à 9.

    Un grand bravo aux traducteurs pour ce travail de titans :

    http://vim.dindinx.net/index.php?p_menu=avancement
    • [^] # Re: Traduction de la documentation de Vim en francais

      Posté par (page perso) . Évalué à -2.

      Il reste les deux tiers des documents à relire, mais à mon avis, ils ne le seront jamais...

      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 (page perso) . Évalué à 8.

    J'ai refait mes paquets pour cette version finale, il sont ici :
    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...
  • # Petit bemol

    Posté par . Évalué à 8.

    Bon, vim est mon editeur préféré mais ça tout le monde s'en fout.
    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 . Évalué à -3.

      Le langage de script courant est vraiment dégueu et mal fait. ça n'encourage pas à participer.
      Pire qu'Emacs lisp?
      • [^] # Re: Petit bemol

        Posté par . Évalué à 3.

        Marrant tous ces gens qui crachent sur lisp...
        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 (page perso) . Évalué à 7.


          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


          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 . Évalué à 4.

            bah pour les fichiers de config, je vois pas où est le problème, tu utilises ViM et... euh, non rien.

            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 . Évalué à 3.

            Pour ça, tu peux utiliser emacs lui-même, il a une interface pour changer les options, elle est bien foutue, avec un arbre des configs et pas compliquée à utiliser. Oui Emacs sait configurer emacs !! ;)

            --
            Jedaï
    • [^] # Re: Petit bemol

      Posté par . Évalué à 10.

      Tu es libre d'utiliser le langage de script qui te plait pour les scripts vim : python, ruby, tcl, perl, et sûrement d'autres. Le langage vim est le langage natif, qui est une extension des fichiers de configurations de vi.
  • # Et les screenshots ?

    Posté par . Évalué à 1.

    Ou au moins des copier coller de terminaux :)
  • # Bureautique ?

    Posté par (page perso) . Évalué à 10.

    Salut à tous,

    C'est une blague de voir cette dépêche dans la section bureautique ou est-ce un clin d'½il au célèbre fake^Warticle de Microsoft prônant Word face à vi :)

    Étienne.
  • # ceci n'est pas un troll ...

    Posté par . Évalué à 6.

    Je sais que vim est vénère ,aduler ; que s'il y avait un jeu olympique des éditeurs ils serais juge au même titre qu' Emacs.
    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 . Évalué à 6.

      Kate est en effet lentement mais surement en train de mettre d'accord vim et emacs :

      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 (page perso) . Évalué à 8.

        Pour moi, la différence majeure entre vim, emacs et kate n'est pas le nombre de fonctionnalité mais la façon d'éditer un texte.

        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 . Évalué à 8.

          Je propose une autre difference beaucoup plus simple: vim comme emacs, nano et beaucoup d'autres sont des editeurs fonctionnant egalement sur des terminaux textes, je ne crois pas que kate rentre dans cette categorie ce qui le met hors jeux pour nombre d'utilisations (kde sur un serveur, c'est pas courant, enfin j'espere... :), pas si facile de s'inserer dans un troll historique :-)

          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 . Évalué à 2.

            Oui, sauf qu'avec Kate tu peux editer ton fichier sur le serveur depuis ton laptop sous KDE depuis ton jardin avec Wifi: fish power.
            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 (page perso) . Évalué à 10.

        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 ?

        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 . Évalué à 5.

        mais ? kate est en ligne de commande maintenant ?
        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 . Évalué à -3.

          kate ca marche aussi dans un ssh, avec un serveur X, et ssh -X :)
          • [^] # Re: ceci n'est pas un troll ...

            Posté par (page perso) . Évalué à -2.

            plus réaliste, avec les KIO fish:/ et sftp:/ :p
          • [^] # Re: ceci n'est pas un troll ...

            Posté par (page perso) . Évalué à 0.

            Surtout kate ça marche aussi à travers SSH grâce aux KIO slaves de KDE. Tu ouvres ton document avec "fish://user@serveur:chemin/vers/ton/document"
            Et tout est transparent, et pas besoin de X sur le serveur.
            • [^] # Re: ceci n'est pas un troll ...

              Posté par . Évalué à 3.

              1-1 : vim peut aussi le faire

              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 (page perso) . Évalué à 2.

                Mais toutes les applications KDE pareil, donc 2-1 pour kate.

                ?
                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 . Évalué à 10.

      Ca depend si tu utilise souvent ton editeur ou pas. Pour moi qui passe mes journees a developper, donc a editer des fichiers, apprendre VI a ete un investissement en temps qui a ete largement rentabilise vu le gain de productivite.

      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 . Évalué à 2.

        Mouai, et comment tu sais que ça fait X lignes?
        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 (page perso) . Évalué à 3.

          Les marques existent dans vim, mais surtout ce qui existe dans vim et pas dans vi, c'est le mode visual qui te permet de sélectionner un bloc.

          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 . Évalué à 4.

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

          * 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 (page perso) . Évalué à 1.

          Tu ne sais pas faire une soustraction ?

          Lorsque tu utilises Vim tous les jours, tu n'oublie pas les fonctionnalitées ;)
    • [^] # Re: ceci n'est pas un troll ...

      Posté par (page perso) . Évalué à 4.

      Un des gros avantages de vim que j'apprecie personellement (et qui est au passage le truc le plus deroutant pour les debutants), c'est qu'il y a deux modes d'editions :

      - 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 (page perso) . Évalué à 2.

        Les deux modes sont aussi un inconvénient. (en fait ce n'est pas deux mais plus si on compte le mode visuel...)
        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 (page perso) . Évalué à 5.

          Heu... Et quel est le problème pour lancer emacs via SSH ?
          • [^] # Re: ceci n'est pas un troll ...

            Posté par (page perso) . Évalué à 5.

            A l'epoque ou j'ai switcher entre emacs et vi j'avais une connexion net lente et chere, donc le premier probleme est la bande passante utilisee par emacs qui est nettement plus importante que celle utilisee par vi. Emacs ce trouvais donc etre super lent et au final me coutais plus cher en temps de connexion (si on met de coter le temps d'apprentissage du vi qui m'a coute cher lui-aussi...)

            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 . Évalué à 3.

          Pour éviter ce problème, placer "set showmode" dans son ~/.vimrc.
          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 (page perso) . Évalué à 1.

            Il est actif, le probleme, a l'epoque, etait que je regardais mon clavier pour taper et pas l'ecran...
            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 . Évalué à 2.

            En ce qui me concerne, ce que je trouverais vraiment pratique, ce serait que la couleur d'arrière-plan change en fonction du mode.
            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 . Évalué à 2.

              Tu as déjà le curseur qui n'est pas pareil en fonction du mode.
            • [^] # Re: ceci n'est pas un troll ...

              Posté par (page perso) . Évalué à 3.

              Tu peux executer une commande quand tu rentres/sors du mode insertion. Par exemple, tu peux charger un fichier de coloration en ajoutant les 2 lignes suivantes dans ton fichier $HOME/.vimrc :

              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 (page perso) . Évalué à 3.

          Si tu as sauvegardé juste avant, il suffit de faire :e! pour récupérer le fichier tel qu'il était lors de la dernière sauvegarde.
      • [^] # Re: ceci n'est pas un troll ...

        Posté par . Évalué à 5.

        Tu te deplace a coup de page-up ou page-down (j'ai jamais pu me rappeler le racourci pour les sauts de pages)

        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 (page perso) . Évalué à 3.

          Tu as raison. Ce qui reste interessant tout de meme, c'est que comme tu le constates, je suis loin d'utiliser toute la puissance de vi. Et pourtant, c'est deja suffisant pour moi pour creer un gain de productivite significatif.

          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 (page perso) . Évalué à 3.


      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 ?


      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 . Évalué à 5.

        J'ajoute, le plus important en ce qui me concerne:

        * 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 . Évalué à 3.

          La presence de Vi sur tous les clones d'Unix au monde n'en fait pas le meilleur editeur pour autant. Sinon Windows est le meilleur OS au monde.
          • [^] # Re: ceci n'est pas un troll ...

            Posté par . Évalué à 3.

            Ce n'est pas ce que j'ai voulu dire: je pensait plutôt que ça en fait un éditeur qu'il est utile de savoir utiliser, surtout en cas d'urgences (en l'occurence, pour un unixien, plus utile que de savoir utiliser windows ;).
    • [^] # Re: ceci n'est pas un troll ...

      Posté par (page perso) . Évalué à 3.

      mais mon temps est précieux


      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 . Évalué à 3.


      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 ??



      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 . Évalué à 1.

      Je comprend ton point de vue.
      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 (page perso) . Évalué à 4.

    Ayant dû apprendre vi sur HP-UX il y a plus de 16 ans, j'ai acquis beaucoup d'automatismes sur cet éditeur. Il est aussi puissant qu'il est empoisonnant pour un débutant (je m'en souviens).
    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 (page perso) . Évalué à 2.

      oui, l'historique des fonctions c'est bien. La complétion de ces fonctions c'est formidable, même si elle est moins puissante que celles des shells évolués, on peut quand même la configurer pour par exemple avoir plus grand prefixe, puis liste.
      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 . Évalué à 2.

        Vim7 utilise les fichiers de vocabulaire d'OpenOffice.org, donc toute la roue n'est pas réinventée ;)
        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 . Évalué à 3.

    Je suis toujours etonne de constater qu'hors Vi(m) et Emacs point de salut. Ah si ! Kate, et dans ce cas, hors KDE point de salut (je n'aime pas etre enchaine a un environnement particulier). Il y a d'autres editeurs, par exemple Nedit, qui est vraiment tres tres bien, aussi bien pour developper (coloration syntaxique, surlignage des parenthese associees, etc...) que pour manipuler des donnees ASCII (avec la selection de colonnesau sein du texte). Les raccourcis clavier de Vi ? On dit qu'ils sont plus pratiques car ils utilisent des touches alphanumeriques, donc plus proches du texte qu'on tape, et pas les touches "exotiques" comme "Insert" ou "Delete". Oui, sauf que c'est tres perturbant car on doit faire sans arret la bascule entre le mode edition et le reste, qui utilisent les memes touches. Et le gain, si on exclut justement la necessite de basculer sans arret, il est minime. Vi(m) est tres utile, et je l'utilise quotidiennement a travers SSH, neanmoins je retrouve Nedit avec joie a chaque fois, pour sa convivialite simple et neanmoins puissante. Bref, Vi/Emacs, il faut etre tordu pour les elire meilleur editeur, ou simplement vouloir se la jouer geek.
    • [^] # Re: Nedit ?

      Posté par (page perso) . Évalué à 2.

      Il y a scite qui est assez connu et marche meme sous windows. Il y a plein de mecs dans ma boite qui l'utilisent pour editer et executer du python.

      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 . Évalué à 1.

        On aurrait pu aussi parler d'Eclipse.

        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 . Évalué à 2.

          Hum... Comparons ce qui est comparable :

          * 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 . Évalué à 2.

            Hum... Comparons ce qui est comparable :

            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 (page perso) . Évalué à 2.

            * Vim prends quelques Ko de mémoire tandis qu'Eclipse peut atteindre les centaines de mega (situation courante au boulot : 250 Mo)

            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 . Évalué à 1.

      Kate, et dans ce cas, hors KDE point de salut (je n'aime pas etre enchaine a un environnement particulier).

      Kate marche très bien sous Gnome.
      • [^] # Re: Nedit ?

        Posté par . Évalué à 2.

        Hum... j'ai l'impression que t'as marché dedans.
    • [^] # Re: Nedit ?

      Posté par . Évalué à 1.

      Je pense que tu oublies LA killer-feature de Nedit : l'apprentissage en live de macros avec Alt+k et le "replay" avec Ctrl+k. C'est surpuissant, j'ai jamais vu ca ailleurs, je m'en sers tout le temps.
      • [^] # Re: Nedit ?

        Posté par (page perso) . Évalué à 6.

        c'est comme le q de vim ?
        (qa pour enregistrer en live la macro nommée a, @a pour la replayer)
        • [^] # Re: Nedit ?

          Posté par (page perso) . Évalué à 4.

          Et bien sûr qA pour ajouter des trucs à une macro commencée, et comme en fait la macro est enregistrée dans une mémoire tampon classique (de a à z), "ap pour l'afficher (de préférence sur une ligne vide), toutes les fonctionnalités habituelles de Vim pour l'éditer, et 0"ad$ pour mémoriser la version corrigée.
        • [^] # Re: Nedit ?

          Posté par (page perso) . Évalué à 2.

          ce qui m'est indispensable dans Vim c'est la touche "." en mode commande

          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 (page perso) . Évalué à 2.

            Et en plus, on peut la répéter, comme la plupart des autres commandes : 5. (refais cinq fois ce que je viens de faire).

            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 . Évalué à 2.

          En effet :) Je note et je me mets serieusement a vim.
          • [^] # Re: Nedit ?

            Posté par (page perso) . Évalué à 1.

            Si tu veux passer à Emacs, c'est

            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 . Évalué à 1.

    Salut,

    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 (page perso) . Évalué à 2.

      > quel est le langage des script vim ? et que fait-on avec ?

      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 . Évalué à 3.

      - 50 langues pour la correction orthographique ? Pourquoi pas 150 ? Et quel interet si on code seulement ?

      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 . Évalué à 1.

      Pour répondre brièvement, de la part de quelqu'un qui comme toi utilisais vi depuis une 15aine d'années et emacs pour tout ce que vi ne permettait pas, on peut dire que vim est un vi avec tout ce que peut faire emacs _si j'en ai besoin_... Depuis je n'utilise plus que vim, bien content de n'avoir qu'un seul éditeur à mémoriser depuis tant d'années...
    • [^] # Re: des questions

      Posté par . Évalué à -1.

      >50 langues pour la correction orthographique ? Pourquoi pas 150 ? Et quel interet si on code seulement ?

      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 (page perso) . Évalué à 6.

    C'est triste, tout se perd... Suis-je bien en train de lire linuxfr ? Je n'arrive à en croire mes yeux !
    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.
  • # Dictionnaire et undo tree ?

    Posté par . Évalué à 1.

    Je voulais savoir si certains d'entre vous ont eu le temps de tester le dictionnaire 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.

    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 . Évalué à 1.

      >Je voulais savoir si certains d'entre vous ont eu le temps de tester le dictionnaire
      >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 à ceux qui les ont postés. Nous n'en sommes pas responsables.