Journal Sortie de Vim 7.1

Posté par  .
Étiquettes :
0
16
mai
2007
Vim 7.1 est sorti, il ne s'agit pas d'une version majeure, mais d'une version dite de "maintenance" afin d'y inclure tous les patchs (environ 260) sortis depuis la version 7.0.

Pour la petite histoire, j'ai trouvé un petit bug dans la version 7.1a (dans la complétion automatique quand on est en mode édition de droite à gauche), que j'ai reporté mais qui ne sera pas corriger de suite :(

Sinon cet éditeur m'impressionne toujours autant, je l'utilise depuis 7 ans et il y'a toujours une petite fonctionnalité à découvrir, dont certaines assez impressionnante pour un si "petit" éditeur de texte. L'aide est aussi très intéressante à lire et à parcourir.

A installer à partir de www.vim.org

  • # Déjà vu

    Posté par  (site web personnel) . Évalué à 4.

    http://linuxfr.org/~plic/24454.html

  • # "petit"

    Posté par  . Évalué à 3.

    un si "petit" éditeur de texte
    c'est vrai que 32Mo de sources c'est tout petit comme éditeur de texte ...
    (téléchargé sur le site et extrait)

    • [^] # Re: "petit"

      Posté par  . Évalué à 6.

      plus petit qu'emacs en tout cas : 79Mo de sources.
      (téléchargé sur le site et extrait)

      :-)

      • [^] # Re: "petit"

        Posté par  . Évalué à 3.

        quel rapport ?

        • [^] # Re: "petit"

          Posté par  . Évalué à 10.

          Entre un éditeur de texte et Emacs ?

          Aucun, effectivement ;o)

          • [^] # Re: "petit"

            Posté par  . Évalué à 4.

            Elle est vieille mais c'est l'occasion de la replacer (je ne sais pas de qui c'est, par contre) :
            emacs est pas trop mal comme système d'exploitation, il ne lui manque qu'un éditeur de texte...

      • [^] # Re: "petit"

        Posté par  (site web personnel) . Évalué à 3.

        Ah, ben c'est pour ça alors ! vim c'est du C, emacs du lisp. Un code en lisp étant 10 fois plus compact que l'équivalent en C on en conclue qu'emacs est 25 fois mieux que vim (et 125 fois mieux qu'elvis) :)
        Hmm, m'en vais me cacher dans /dev/null...

  • # editeur console/gui

    Posté par  . Évalué à 6.

    Ce que je reproche à ces éditeurs console comme vim et dans une moindre mesure emacs, c'est l'obligation de passer par la doc pour faire quelque chose, elle même contenue dans l'éditeur.

    En gros, il faut chercher comment chercher dans la doc, et ensuite on peut chercher les fonctionnalités. La phase d'apprentissage et de prise en main est plutot longue par rapport aux éditeurs GUI, donc on trouve les fonctionnalités voulues plus simplement en se baladant dans les menus...

    C'est ça qui me rebute et me fait continuer à utiliser un éditeur "graphique". D'autant plus que sous Linux, les éditeurs GUI "légers", ça n'existe pas ou c'est beaucoup moins léger qu'un équivalent windows.

    • [^] # Re: editeur console/gui

      Posté par  (site web personnel) . Évalué à 2.

      >C'est ça qui me rebute et me fait continuer à utiliser un éditeur
      >"graphique". D'autant plus que sous Linux, les éditeurs GUI "légers",
      >ça n'existe pas ou c'est beaucoup moins léger qu'un équivalent
      >windows.

      Tu as essayé SciTe ?
      http://www.scintilla.org/SciTE.html

      Si oui tu en penses quoi ?

    • [^] # Re: editeur console/gui

      Posté par  . Évalué à 3.

      > D'autant plus que sous Linux, les éditeurs GUI "légers", ça n'existe pas
      Mousepad ? Leafpad ? scite ?

      • [^] # Re: editeur console/gui

        Posté par  . Évalué à 2.

        Enfin, il y a léger et léger. Sur une même machine, compare PSPad (ou ultraedit) sous windows qui est extrèmement complet, et ces 3 éditeurs (qui sont bien plus limités).

        Si tu ne vois pas de différence, mois j'en vois :
        - réactivité de l'interface (pas forcément imputable au logiciel, mais au toolkit, au X)
        - efficacité de l'interface : pas de boutons / polices énormes, dispositions des boutons, zone de travail, barres latérales, look "sobre" et concis.

        Pour moi ce sont 2 critères indispensables à mon confort quand je code.

        Quand à Gvim, la gui est franchement pas confortable du tout, emacs/xemacs c'est pareil.

        Enfin, le fait que vous me donner des liens vers les docs de vim/emacs justifie le tout : je n'ai jamais eu besoin de doc pour utiliser pspad, eclipse ou tout autre editeur qui dispose d'une gui bien pensée.

        C'est le problème des outils "console" qui se voient greffer une GUI, car le point central reste l'éditeur, alors qu'avec un editeur à la base pensé avec GUI, l'intégration est bien meilleure.

        Tout ceci fait que c'est plus confortable pour moi de bosser sous windows que sous linux.

        alors je jette la pierreà Vim/emacs, mais je pense que le principal problème vient des toolkits graphiques , de leur apparence et des performances de X/GTK/Qt.

        • [^] # Re: editeur console/gui

          Posté par  (site web personnel) . Évalué à 3.

          Trop gros, passeras pas.

        • [^] # Re: editeur console/gui

          Posté par  (site web personnel) . Évalué à 2.

          Personnellement, j'utilise en plus de vi l'éditeur nedit qui sais faire des sélections carré (Ctrl+Souris) et les déplacer. C'est très pratique.

        • [^] # Re: editeur console/gui

          Posté par  . Évalué à 4.

          scite me semble pas mal quand même par rapport à ce que tu recherches, il est léger, complet, propose un environnement de dev qui semble complet, il est modulable.

          Pour ma part je préfère kate, qui a en plus une intégration konsole sympa. Je ne le trouve pas spécialement lourd non plus, et réactif même sur de gros fichiers, mais bon, cela doit dépendre des besoins de chacun (je ne suis pas développeur C ou C++).

          En ce qui concerne les éditeurs console, j'utilise vim surtout lorsque je dois éditer des fichiers de conf en console, donc j'utilise des fonctions vraiment de base.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: editeur console/gui

          Posté par  . Évalué à 3.

          J'utilise scite tous les jours, j'ai déjà testé ultraedit (bon, ok, c'était à l'époque où j'étais encore sous windows, donc windows 95), et même s'il m'avait bluffé, je vois pas vraiment ce que scite a de moins par rapport à lui...

          > Tout ceci fait que c'est plus confortable pour moi de bosser sous windows que sous linux.
          Exactement l'inverse ici :)
          Même si scite existe sous Windows, je trouve qu'il s'intègre très mal au reste de l'environnement de dev (compilateur/interpréteur, console,...), de même pour ultraedit. Je crois que tu as oublié le point fort d'Unix: la coopération de petits outils indépendants ; et que tu as essayé d'utiliser scite comme UltraEdit, d'où ta déception... Mais si tu utilises scite pour ce qu'il est (une simple brique dans un env de dev "éclaté"), tu verras que ça correspond à ce que tu sembles demander, et tu pourras probablement pas revenir sous ultraedit ;)

    • [^] # Re: editeur console/gui

      Posté par  (site web personnel) . Évalué à 10.

      Pas mal du tout !
      je sais que beaucoup font le pont mais, tu peux revenir vendredi stp ?

    • [^] # Re: editeur console/gui

      Posté par  . Évalué à 3.

      Vim dispose de gvim, qui est un vim avec une interface graphique, un menu, etc.

      Emacs également.

      En plus ils sont léger.

    • [^] # Re: editeur console/gui

      Posté par  (Mastodon) . Évalué à 0.

      D'autant plus que sous Linux, les éditeurs GUI "légers", ça n'existe pas ou c'est beaucoup moins léger qu'un équivalent windows.

      Il te faut xedit

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: editeur console/gui

      Posté par  . Évalué à 3.

      Franchement je trouve que Vim est l'un des rares programme où la doc est vraiment faites avec soin.

      OK bien sur, un éditeur amodal est plus facile et direct à prendre en main, mais toute la puissance de vim réside justement dans ces différents modes, et ses commandes. Et là je peux te dire que tu es toujours sûr de pouvoir faire quasiment n'importe quel traitement dans tes fichiers, vim a toujours la solution. Un éditeur amodal (classique) est bcp moins riche.

      Pour la doc, là je ne suis pas d'accord :
      - déjà tu as un tutoriel très bien fait, qui te donne vraiment les bases et qui permet de t'améliorer très vite
      - après la doc est vraiment faite pour te "former", les choses y sont très bien expliquées et tu peux trouver plusieurs axes :

      - Vue Générale
      - Manuel de l'utilisatuer
      - Comment faire pour...
      - Trouver...
      - sans compter le :h pr te donner de l'aide sur la commande "truc", on peut pas faire plus simple et rapide.

      Et en plus si avec ça tu ne trouves pas t'as une communauté d'utilisateurs mailing list, très réactive, et sympa. J'ai pu toujours avoir très rapidement des réponses à des problèmes pas évidents résolus grâce a leur aide et à vim.

      Donc je pense que c'est vraiment lui faire un mauvais procès que de dire qu'il est mal documenté ou pas facile d'accès, et qu'avant de découvrir la beauté de cet outil, il faut faire un peu d'effort au début mais qui sont vite récompensés après.

      • [^] # Re: editeur console/gui

        Posté par  . Évalué à 3.

        je crois que son propos, dans le fond, n'est pas de critiquer le programme sur sa doc, le soutien dont il dispose (forum, irc, mailing list, etc..) mais sur, justement, le fait qu'il ne soit pas intuitif...

        Je ne peux pas lui donner tort, c'est toujours un plaisir de tomber sur un programme quel qu'il soit, bien concu et intuitif, où tu peux commencer à travailler, à produire tout en découvrant le logiciel : où tout tombe sous le pointeur de ta souris lorsque tu le cherches...

        Vim, en ayant des modes et des raccourcis clavier, échappe à ce tout tout de suite... ca n'a rien à voir avec la qualité du programme en lui-même, ca a à voir avec la conception qui la découle d'une affaire de gout et/ou d'opinion.

        ceci dit : je n'aime pas les éditeurs en consoles non plus... je préfére un Kate super lourd qui utilise un max de mémoire dans un KDE super décoré avec accélération 3D et compagnie... BSD et GNU/Linux ont la possibilité d'être beaucoup plus user-friendly et beau que les autres, faut pas s'en priver... :-D

    • [^] # Re: editeur console/gui

      Posté par  . Évalué à 3.

      Ça se rapproche grandement de cette discution qui à lieu en ce moment à propos de blender.

      http://linuxfr.org/comments/832398.html#832398

      Pour résumer, je pense que ce genre de programme demande un investissement, car le but et d'augmenter au maximum la productivité, aux prix d'un apprentissage plus long.
      Je pense que quand on se sert souvent d'éditeur de texte, c'est un investissement non négligeable.
      Par contre, si c'est pour taper un mémo tout les 36 du mois, autant rester sous le gedit / kate et autres.

      Les trucs longs à apprendre mais que je ne regrette pas parce que maintenant, je ça me fait gagner beaucoup de temps :
      -- la dactylographie
      -- le dvorak
      -- vim
      -- fvwm
      -- http://les.filles.saimal.fr faut s'en méfier, c'est pas toujours sincère

  • # Omni completion pour c++

    Posté par  . Évalué à 0.

    Vous utilisez quoi comme script pour écrire votre code c++ ?

    • [^] # Re: Omni completion pour c++

      Posté par  . Évalué à -1.

      Ben... Rien. Je n'utilise jamais de complétion, et ça ne me manque pas...

    • [^] # Re: Omni completion pour c++

      Posté par  . Évalué à 1.

      J'utilise omnicppcomplete (http://www.vim.org/scripts/script.php?script_id=1520), et j'ai rajouté ça dans mon .vimrc pour générer/mettre à jour les tags :
      set tags+=~/.vim/systags,~/.vim/tags
      command! GenTags :!exuberant-ctags -V -R -f ~/.vim/tags --c++-kinds=+p --fields=+iaS --extra=+q .
      command! GenSysTags :!exuberant-ctags -V -R -f ~/.vim/systags --c++-kinds=+p --fields=+iaS --extra=+q /usr/include/qt4/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.