Chasse aux bugs ouverte pour Vim 7.0

Posté par  . Modéré par rootix.
Étiquettes :
0
28
mar.
2006
Communauté
Vim 7.0b est enfin dans les bacs. Après de long mois de développement, la première version bêta de cette évolution majeure de vim (passage de numérotation de 6.4 à 7.0, c'est dire de l'importance de cette version) est disponible sous unix et win32 pour une chasse aux bugs incontournable.

Vim est déjà apprécié et connu pour sa grande richesse fonctionnelle, mais ce couteau suisse de l'édition de texte, va _encore_ s'enrichir de nouvelles fonctionnalités qui nécessitent d'être testées, éprouvées, corrigées et validées.

Au menu de cette nouvelle version on trouve :
  • l'ajout d'onglet, pouvant contenir chacun plusieurs fenêtres/buffers
  • la correction orthographique par suggestion "en cours de frappe"
  • arbre d'annulation permettant de retrouver tous les états précédents du fichier édité
  • amélioration des scripts Vim (ajout des listes, dictionnaires etc...)
  • meilleur support de l'Unicode
  • complétion intelligente
  • amélioration de la coloration syntaxique

et bien d'autres fonctionnalités encore.

Le développement de Vim tout comme les listes de diffusion ont toujours été très actifs et l'effort de tous sera apprécié.

Un peu avant l'annonce de la mise à disposition de la version bêta, Bram Moolenaar (le leader du projet) en a profité pour dire qu'il allait prochainement intégrer la société Google (à Zurich) pour un poste à plein temps. Cette nouvelle fonction lui permet ainsi d'envoyer tous les dons faits à Vim pour ses projets de soutien en Uganda, via l'association ICCF.

Nous lui souhaitons tous bon courage dans ses nouvelles fonctions.

Aller plus loin

  • # Troll

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

    Je préfère Emacs

    • [^] # Re: Troll

      Posté par  . Évalué à -3.

      vim est mieux : il s'integre mieux dans GNOME avec gvim :)

      • [^] # Re: Troll

        Posté par  . Évalué à 10.

        Oui mais GNOME s'intègre mieux dans emacs que dans vim.

    • [^] # Re: Troll

      Posté par  . Évalué à 10.

      Dans vim, on peut mapper toutes les touches de raccourcis emacs de tel sorte que tu utilises vim tel un emacs.
      Suis pas sûr que le contraire soit possible.

      J'ai rien contre emacs, il fait tout plein de chose (lecteur de news, email, fenete shell, j'en passe etc...) mais il lui manque juste un bon éditeur de texte ;)

    • [^] # Re: Troll

      Posté par  . Évalué à -2.

      Je me pose une question : vous en avez pas marre de lancer des trolls aussi gros que le emacs vs vi ?
      Au départ ça me faisait sourire et des fois c'était même argumenté. Du coup on pouvait apprendre des fonctionnalités de tel logiciel ou tel autre. Mais là, ressortir ce troll encore une fois, qui plus est sans même appuyer une nouvelle fonctionnalité de l'un ou manquante de l'autre, je ne trouve pas ça très intéressant :(

      • [^] # Re: Troll

        Posté par  . Évalué à 10.

        surtout que "vim contre vi-canal-historique" est beaucoup plus pertinent.

        • [^] # Re: Troll

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

          De toute façons, ceux qui utilisent les touches de direction à la place de h j k l sont des faibles. :o

      • [^] # Re: Troll

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

        Je suis à 100% d'accord avec toi. Continuer à troller entre emacs et vim n'est absolument pas intéressant , en effet tout le monde sait que vim est bien meilleur.

    • [^] # L'opinion du Windowsien incurable ...

      Posté par  . Évalué à 10.

      Word 2007 est beaucoup plus ergonomique avec ses effets de transparence, on peut même enregistrer les fichiers C++ en RTF ...

    • [^] # Re: Troll

      Posté par  . Évalué à 10.

      Je préfère Emacs

      Mauvaise tentative de troll. Pour troller de facon efficace on dit "Emacs est bien mieux" ou "vim ca sux" et non pas "je préfère".

      Si on insiste à voulloir dire "je prefere" il est imperatif de rajouter quelquechose comme "et tous ceux qui ne pensent pas comme moi sont des cons" pour bien faire comprendre que ce n'est pas un simple avis.

      • [^] # Re: Troll

        Posté par  . Évalué à 6.

        ou "je préfère, et c'est bien naturel car c'est quand même objectivement la meilleure solution, ..."

      • [^] # Re: Troll

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

        En effet... Je pensais que tout le monde avait saisi l'ironie d'un post dont le titre est "Troll", mais bon...

  • # La gestion de multiple fenêtres

    Posté par  . Évalué à 4.

    Je n'arrive pas à trouver si la gestion de fenêtres multiples avec une seule instance de vim a été ajouté ou pas. (je ne parle pas des splits)

    Quelqu'un en connait plus sur ce sujet?

    • [^] # Re: La gestion de multiple fenêtres

      Posté par  . Évalué à 2.

      Cette fonctionnalité apparaît en 11ème dans la table des votes (http://www.vim.org/sponsor/vote_results.php)

      11) support multiple top-level windows for one running Vim

      Il y'a de très forte chance qu'elle soit intégrer mais par contre en quoi ca consiste, car Vim fait du multi-fenêtrage a la base.
      Donc késako ?
      Serait ce des fenêtres détachables en fin de compte ?

      • [^] # Re: La gestion de multiple fenêtres

        Posté par  . Évalué à 1.

        Du tabbing comme sous Screen ?

      • [^] # Re: La gestion de multiple fenêtres

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        Je sais pas si c'est vraiment de ça qu'il s'agit, mais ne serait-ce pas le fait que lancer 2 fois vim fait que c'est quand même la même instance de vim?

        Exemple concret d'utilisation: faire du copier-coller vim (au clavier donc, en utilisant le presse-papier vim, avec y/p par exemple). Parce que jusqu'à présent, pour faire du copier-coller entre 2 instances différentes de vim, on est limité à ressortir la souris pour utiliser le copier-coller X (sélectionner/clic milieu). Et c'est très très très chiant. Grosse perte de temps.
        Ca doit signifier ça de supporter plusieurs fenêtres de vim pour la même instance du programme.

        Voilà, si c'est ça que signifie ce 11ème point, alors c'est clairement un point majeur que j'aimerais énormément.
        C'est marrant, parce que j'avais récemment vu ds le manuel vim une section client-serveur (-h clientserver), et pendant un moment j'ai cru que c'était ça. Mais en lisant la page du manuel, ben j'ai vraiment trouvé aucun moyen de faire par exemple un simple copier-coller d'un vim à l'autre... :-( Le truc clientserver, à l'heure actuelle, c'est uniquement la possibilité d'envoyer des commandes depuis la ligne de commande ou depuis un autre vim vers le serveur. Moi je veux pas qu'il y ait un vim principal, et pleins de vim d'où on peut envoyer des commandes. Je veux juste que tous les vims soient reliés entre eux.
        Dommage qu'on puisse plus voter, j'aurais voté pour ce point.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: La gestion de multiple fenêtres

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

          Exemple concret d'utilisation: faire du copier-coller vim (au clavier donc, en utilisant le presse-papier vim, avec y/p par exemple). Parce que jusqu'à présent, pour faire du copier-coller entre 2 instances différentes de vim, on est limité à ressortir la souris pour utiliser le copier-coller X (sélectionner/clic milieu). Et c'est très très très chiant. Grosse perte de temps.


          "+gy pour copier
          et
          "+gp pour coller
          C'est pas beaucoup plus rapide, mais c'est un peu mieux

          • [^] # Re: La gestion de multiple fenêtres

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

            Salut,

            je connaissais pas ces commandes (mais, c'est ça qui est bien, on apprend toujours de nouveaux trucs avec vim), mais en l'occurence elles marchent pas avec moi.
            Tu peux m'expliquer? En faisant des recherches dans l'aide, j'ai l'impression que tu veux me faire utiliser le principe des registres, c'est ça? Mais j'ai fait des tests, et ces registres ne sont pas communs d'une instance de vim à l'autre (j'ai enregistré du texte ds un registre, puis ai affiché son contenu; et ensuite ds une autre instance, j'ai affiché le contenu, et c'était vide).

            Ca marche d'une instance de vim à l'autre pour toi? T'as peut-être une option de compilation spécifique?

            Je note que ds le manuel, je lis
            You can also use these commands to move text from one file to another, because Vim preserves all registers when changing buffers

            J'ai donc vraiment l'impression qu'il faut que ce soit la même instance de vim, avec des fichiers dans des buffers séparés. Mais si tu me montres que c'est faisable comme je l'aimerais, je te serai vraiment méga reconnaissant. :-)
            En tous cas, merci dans tous les cas pour ton message, ça m'a permis de découvrir des nouveaux trucs (les registres) dans le manuel. :-)

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: La gestion de multiple fenêtres

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

              A priori, cela ne marche que si ton vim est connecté à X. En effet "+ représente normalement le clipboard de X qui est commun à toutes les applications. Il peut éventuellement y avoir besoin de faire set clipboard+=unnamed pour que ça marche. (Je n'ai pas de X sous la main pour tester.)

          • [^] # Re: La gestion de multiple fenêtres

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

            Quand on édite plusieurs fichiers (exemple vi *.c *.h), on peut copier des données entre les fichiers en utilisant des tampons nommés a, b, c, ... ,z

            Pour copier 5 lignes dans le buffer a (passer en mode commande et placer le curseur sur la première ligne.
            "a5yy
            Pour changer de fichier :
            :n
            :rew
            Pour copier le buffer a
            "ap

        • [^] # Re: La gestion de multiple fenêtres

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

          Exemple concret d'utilisation: faire du copier-coller vim (au clavier donc, en utilisant le presse-papier vim, avec y/p par exemple). Parce que jusqu'à présent, pour faire du copier-coller entre 2 instances différentes de vim, on est limité à ressortir la souris pour utiliser le copier-coller X (sélectionner/clic milieu). Et c'est très très très chiant. Grosse perte de temps.


          Sur mon vim, j'utilise les touches _Y et _P configurées comme suit dans mon ~/.vimrc:

          nnoremap _Y :.w! ~/.vi_tmp<CR>
          vnoremap _Y :w! ~/.vi_tmp<CR>
          nnoremap _P :r ~/.vi_tmp<CR>


          Ca utilise le fichier ~/.vi_tmp comme buffer temporaire pour le copier coller. J'ai aussi configuré les touches __Y1, __Y2, ... __P1, __P2, ... pour avoir plein de buffers différents pour faire du copier-coller entre plusieurs instances de vim.

          Sinon, si on veut vraiment utiliser le buffer de X et utiliser le bouton de la souris pour coller le texte, penser à :set paste et :set nopaste si on ne veut pas que l'indentation automatique déforme tout...

  • # FTP pour téléchargement de la version béta

    Posté par  . Évalué à 5.

    Le lien de la dépêche ne renvoie sur les téléchargements de la version stable 6.4.

    Pour la dernière version bêta aller sur :
    ftp://ftp.vim.org/pub/vim/unstable/

    Version Unix et win3é dispos

  • # version osx disponible aussi

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

    Pour la version osx, il suffit de télécharger les sources par cvs, de faire cd vim-7*/src puis make. Non pas de configure, juste make, et hop, un joli Vim.app tout prêt tout chaud.

    Sinon, vous connaissez un vi-clone qui soit sympa développé et moins omnipotent que vim ? Parce que nvi est vraiment trop minimal, elvis n'a plus l'air d'être développé et pourtant, il lui manque un petit peu de coloration syntaxique et une doc plus lisible pour que je le trouve parfait, yi est excessivement lent. Bref ma quête du vim démélioré n'est pas satisfaite.

    • [^] # Re: version osx disponible aussi

      Posté par  . Évalué à 2.

      Pour la version osx, il suffit de télécharger les sources par cvs, de faire cd vim-7*/src puis make. Non pas de configure, juste make, et hop, un joli Vim.app tout prêt tout chaud.

      ah ba non. mince : tu m'avais mis l'eau à la bouche

      Je fais un tour sur leur forum avant le rapport de bug

    • [^] # Re: version osx disponible aussi

      Posté par  . Évalué à 2.

      N'oubions pas non plus pour OS X le sympathique site http://www.macvim.org qui propose déjà un vim (version ligne de commande) et un vim.app (version carbon) versions 7.0 beta compilés, une application pour permettre de lancer plusieurs instance de vim.app et un un script shell pour executer a partir de la ligne de commande.

      D'ailleurs je me suis servi des versions de vim 7 alpha de ce site depuis quelques mois et n'ai jamais rencontré un seul problème.

  • # Libre ne veut pas dire ne nécessitant pas de fianancement.

    Posté par  . Évalué à -4.

    Je pense que ça fait prendre conscience que logiciel libre ne veut pas dire logciel n'yant pas besoin de financement.

    C'est dommâge, je pense qu'un grand nombre de projets aurait besoin d'un coup de pouce financier et qu'ils n'ont bénéficient pas, les mentalités devraient peut-être évoluer à ce niveau là.

    Mais c'est un problème récurrent, comment financer le libre ? Avec toutes les problématiques que ça soulève.

  • # Mise à jour de la beta

    Posté par  . Évalué à 5.

    Depuis le post, il y a une petite évolution on est passé à la version 7.0c. Pour ceux qui ont déjà télécharger la 7.0b, vous pouvez récupérer le diff ici : ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.0b-7.0c.diff.g(...)

  • # Completion automatique

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

    Pour activer la completion auto intelligente, il faut faire ctrl-x ctrl-o en mode insertion.

    Pour les autres nouveautés :

    :help version7

    • [^] # Re: Completion automatique

      Posté par  . Évalué à 9.

      Pour activer la completion auto intelligente, il faut faire ctrl-x ctrl-o en mode insertion.
      vim se met a utiliser des commandes emacs, ou va t on ?

    • [^] # Re: Completion automatique

      Posté par  . Évalué à 2.

      Moi je me prends un "E764: Option 'omnifunc' is not set"... c'est normal ? :-/
      Dans :help 'omnifunc' je vois
      {not available when compiled without the +eval
      or +insert_expand feature}


      par défaut c'est censé être compilé avec ? et sinon, je l'active comment ? j'ai essayé --enable-eval au configure mais ça change rien...

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

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

    • [^] # Re: Déjà une dépêche ?

      Posté par  . Évalué à 7.

      Je crois que Vim est une apps suffisement connu et importante pour qu'une RC soit signale.en plus le titre "Chasse aux bugs ouverte pour Vim 7.0" ce justifie plutot bien et anticipe ton commentaire...Pour qu'il est rapport de bug il faut des gens pour rapp...

      • [^] # Re: Déjà une dépêche ?

        Posté par  . Évalué à 0.

        oups veuillez lire "...Je crois que Vim est une apps suffisement connu et importante pour que la version 7 soit signale ..."

        bien-sur c'est absurde de faire un article sur chaque RC.

  • # Et hop, les paquets mandriva gentillement copilé par l'ami rapsys ;)

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

    urpmi.addmedia vim70 http://rapsys.free.fr/mandriva/ with hdlist.cz

    Après y a plus qu'a installer vim-enhanced ou vim-X11

    ps : j'ai ajouté un paquet vim-i18n qui contient les man pages en UTF-8, il entre en conflit avec les man-pages-fr alors il n'est pas obligatoire, installez le a votre convenance ;)

  • # Yzis, c'est le futur

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

    Bonjour,

    Un point interessant a noter dans les fonctionnalites les plus demandees :
    http://www.vim.org/sponsor/vote_results.php

    L'integration dans un autre GUI. Nous, les auteurs de kvim avions fait ce travail et avons finalement renonce a cause de la trop grande difficulte de travailler sur la base de code de vim, et le manque de volonte de Bram de modifier Vim dans ce sens.

    Donc la 3e fonctionnalite la plus demandee n'est pas prete d'arriver.

    En revanche, nous avons demarre un autre projet, yzis, qui est un clone de vim sans les ``limitations'' imposees par l'architecture de vim. Quelques choix techniques :
    - dev en C++
    - scripting en lua
    - moteur de syntaxe de kate
    - gui en Qt, KDE et ncurses pour l'instant (sans limitations d'autres possibilites)
    - utilisation de libyzis comme moteur vi independant (facon scintilla)
    etc.

    Plus de details sur :
    http://linuxfr.org/2005/02/16/18311.html
    http://www.yzis.org

    Le developpement a un peu ralenti ces derniers mois mais repart, avec notamment le portage complet a Qt4 qui nous permettra d'avoir un yzis Windows, MacOs et Linux sous GPL tres facilement.

    On est pas au niveau de vim question fonctionnalite et stabilite, mais on s'en approche a grand pas. Et c'est vraiment facile de participer grace a l'architecture propre en C++ (l'architecture de vim et a s'arracher les cheveux).

    • [^] # Re: Yzis, c'est le futur

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

      Pour l'intégration dans une autre GUI, pida y arrive :)
      http://pida.berlios.de/

      Pour rappel, pida est un framework d'IDE. En gros, il est livré avec une interface de base, que l'on peut étofé et remanipuler avec plusieurs plugin. A la base développé pour faire du python, il peut sans problème être utilisé pour coder dans n'importe quel autre langage :)

      • [^] # Re: Yzis, c'est le futur

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

        Interessant.

        Pida marche parce que vim utilise une fenetre gtk par defaut et que pida est en gtk et gtk dispose d'un mecanisme pour incruster ses propres fenetres. Faire l'integration de vim gtk dans un widget Qt est beaucoup beaucoup plus complique puisqu'on dependait d'une fonctionnalite, XEmbed, qui avait ete incompletement implementee et peu testee par Trolltech et Gtk.

        J'ai pas essaye, mais je pense qu'il reste des limitations. Le protocole de communication vim-server vim-client est plutot leger et ne permet par de faire un certain nombre de chose. Notamment, si on envoit une commande via ce canal, on ne peut pas savoir si la commande a reussi ou pas.

    • [^] # Re: Yzis, c'est le futur

      Posté par  . Évalué à 3.

      Yzis ca a l'air vraiment bon. D'ailleurs, quand j'ai vu la news sur vim7 je suis alle
      faire un tour sur votre site, histoire de prendre des nouvelles.

      Il y a 2 questions existentielles que je me pose neammoins:
      - est-ce que pour les accros au python il est prevu d'avoir une "interface" de scripting pour ce langage (plutot que Lua, je parle pas le Lua tres couramment) ?
      - est-ce qu'il est prevu d'avoir un module de compatibilite pour les scripts vim (de sorte qu'il serait possible de reutiliser toute la base deja existante de ces scripts dans Yzis) ?

      Voila-voila...

      Ou sinon, vu que vous avez fini le portage vers Qt4, quelles sont vos impressions par rapport a cette nouvelle version de Qt ?

      • [^] # Re: Yzis, c'est le futur

        Posté par  . Évalué à 4.

        a priori Lua est et restera le langage de 'base'
        neanmoins lorsqu'on aura finit la premiere version stable (a priori synchro avec KDE4 si tout va bien), on pourra envisager de rajouter les interfaces vers d'autres langages de scripts.
        (je ne veux pas le faire avant pour pas que les developpeurs principaux se prennent trop la tete avec des choses qui me paraissent a l'heure actuelle 'gadget' ;)
        Lua est un langage vraiment sympa et tres leger, facilement améliorable et dont l'integration en C est sympa.

        concernant le module de compatibilité, Philippe a commencé un script Lua pour convertir les scripts vim en lua, c'est pas chose facile (conversion de regexps, des 0 qui veulent pas dire 'false' em Lua ...), donc on aura besoin d'aide pour faire ca.
        de meme, ca ne me parait pas 'indispensable' comme fonctionnalité ;)

        Sinon si vous avez besoin d'un script particulier, ca ne coute rien de poster un mail sur nos listes ou sur le site. Un volontaire pour s'entrainer a Lua passera peut-etre par la :)
        et a defaut, ca nous aidera a voir quelles interfaces sont nécessaires entre le script et la librairie pour faire que ca soit plus simple a scripter.

        au niveau Qt4, ca correspond a 95% a ce que j'esperais, a savoir des interfaces beaucoup plus claires, une separation en plusieurs librairies (ce qui fait que nyzis n'a plus besoin de charger une lib de 10Mo pour demarrer, le lancement est instantanné maintenant), et des perfs vraiment améliorées globalement comparées a qt3.
        les 5% qui restent concernent QPrinter, mais je suis trop exigeant envers Qt ;) (j'aurais voulu que ca soit dans QtCore et pas dans QtGui ;o)

        Mik

        • [^] # Re: Yzis, c'est le futur

          Posté par  . Évalué à 6.

          Ok, merci pour ces infos...

          ca ne me parait pas 'indispensable' comme fonctionnalité
          Je pense au contraire que c'est tres important.
          Avoir la tres grande majorite des scripts vim accessibles depuis Yzis est il me semble une condition necessaire pour faire switcher un maximum d'utilisateurs vim...

          En tout cas, j'aime bien la philosophie de base de Yzis (une bibliotheque de base que l'on peut integrer un peu n'importe ou)...

          • [^] # Re: Yzis, c'est le futur

            Posté par  . Évalué à 2.

            si Yzis fait ses preuves les gens auront la volonté de refaire leur ptit script en Lua si c'est nécessaire ;)

            mais a nouveau, si des gens font le script pour traduire les fichiers Vim, tres bien, je prends !
            Mais moi je ne le ferai pas ;) (ou alors faudrait vraiment que je m'ennuie sévère ;)
            Je pense qu'on a des choses bien plus intéressantes à développer dans Yzis.
            d'autant plus que 90% des scripts de Vim sont utilisés par 1% des utilisateurs de Vim, ce qui fait qu'on ira bien plus vite de réécrire les 10% "vraiment" utilisés à la main ;)

            sinon traduire les 10 lignes du .vimrc des gens, franchement l'utilisateur peut le faire ;) (à un moment ou un autre l'utilisateur devra s'habituer à la conf d'Yzis de toute facon, la conf 'de base' est un bon moyen pour s'y habituer en douceur).
            Le 'tout-auto-a-la-mode-windows-que-je-fais-plein-de-choses-partout-sans-te-le-dire', je trouve pas que ca soit une excellente idée ;)

            Enfin, nous aurons normalement les options de base visibles via une jolie interface graphique "click-click" pour les vrais débutants, bien plus simple que le .vimrc ;)
            (voire toutes les options peut-etre si on arrive à définir une méthode d'organisation et d'affichage propre et claire dans une GUI ce qui n'est pas forcément évident quand on a x centaines d'options)

            Mik

          • [^] # Re: Yzis, c'est le futur

            Posté par  . Évalué à 1.

            Je suis d'accord avec Sébastien, c'est indispensable! Déjà que je ne vois pas à la base pourquoi je passerai de gvim à yzis mais si en plus je perds au passage tous les scripts que j'utilise...
            gvim c'est un outil de production pour moi, il est fiable, fait ce que je veux, je ne vais donc pas en changer comme ça! D'autant plus qu'actuellement il semble très centré kde.

        • [^] # Re: Yzis, c'est le futur

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

          au niveau Qt4, ca correspond a 95% a ce que j'esperais, a savoir des interfaces beaucoup plus claires, une separation en plusieurs librairies (ce qui fait que nyzis n'a plus besoin de charger une lib de 10Mo pour demarrer, le lancement est instantanné maintenant), et des perfs vraiment améliorées globalement comparées a qt3.

          nyzis dépend de QT? Le but de faire une libyzis était pas justement de pas dépendre de QT pour la version console? Je trouve dommage cette dépendance (enfin, d'un autrre coté, j'utilise nvi et emacs, donc mon avis... ;-))

    • [^] # Re: Yzis, c'est le futur

      Posté par  . Évalué à 1.

      Je tourne en rond sur ton site, je ne trouve pas la signification de Yzis. Ca veut dire quoi ?

      Sinon pourquoi Lua ? (je n'aurais rien préféré d'autre c'est pour savoir ;)

      • [^] # Re: Yzis, c'est le futur

        Posté par  . Évalué à 2.

        ce qui nous a plu avant tout c'est la facilité d'integration en C ainsi que la simplicité du langage lui-meme.
        et enfin c'est tres leger tout en etant tres rapide.

        apres savoir si c'est "mieux" que Python ou Perl, je pense que c'est une simple question de gouts et de couleurs ;), et surtout l'usage qu'en font les utilisateurs.

        Mik

        • [^] # Re: Yzis, c'est le futur

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

          Pour faire court sur le choix lua vs python, disons que lua, en deux jours t'as un truc fonctionnel et utilisable.

          En python, apres 2 semaines de bataille avec boost ou l'api C de python, t'as un truc qui marche a peu pres mais qui compile pas systematiquement sous toutes les plateformes (notamment sous windows, je m'arrache les cheveux).

          En tant que fan de python, je suis pour python qui a plus de potentiel mais clairement, lua marche beaucoup mieux aujourd'hui et pour longtemp et remplit 95% du besoin.

          J'ai un convertisseur vim -> lua qui marche pas mal sur des scripts pas trop complexes. Ca m'interesse d'avoir des scripts vim qui des gens utilisent pour pouvoir tester le convertisseur de facon un plus poussee et valider qu'on a bien toutes les interfaces qu'il faut dans yzis.

  • # Des bugs dans Vim ?

    Posté par  . Évalué à 5.

    C'est bien de faire un beta histoire de débugger toutes ces fonctionnalités, mais moi je trouve qu'en général vim est très très peu buggé...
    Je trouve ça exceptionnel : c'est peut-être le logiciel que j'utilise le plus, je ne me souviens pas avoir vu de bug dedans, et encore jamais aucun plantage en plus de 6 ans d'utilisation.
    Ayant du mal à me mettre à Latex, qui m'avait pourtant bien servi pour un rapport (fait dans vim, bien sûr), j'ai eu du mal à m'adapter aux plantages réguliers de OOo. C'est vrai quoi, j'ai jamais eu le réflexe de sauvegarder mes documents textes toutes les 30s pour éviter le crash pendant mon utilisation de ce merveilleux outils : Vim, mon amour !...

    • [^] # Re: Des bugs dans Vim ?

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

      On peut dire que Bram protege precieusement vim pour qu'il reste tres stable. C'est un peu ce qui nous a oblige a demarrer yzis. Un pour rajouter une configuration en ligne de commande qui n'etait pas utilisee par vim de toute facon (uniquement kvim), ca nous a calme.

      En terme de sauvegarde, ESC : w est la suite de touche que je tape des que j'entre en mode "normal". C'est devenu un pur reflexe et je n'ai jamais besoin de compter sur vim pour me restaurer mes fichiers.

      • [^] # Re: Des bugs dans Vim ?

        Posté par  . Évalué à 1.

        Un pour rajouter -> Un an pour rajouter

        ;)

        Mik. qui lui, curieusement, avait bien compris la phrase quand meme :))

  • # quand même je me pose une quuestion ....

    Posté par  . Évalué à 2.

    Quel est l'intéret de développer un truc tel que vim qui commence à devenir une usine à gaz "a la emacs" ? Si quelqu'un veut une usine a gaz, y en a suffisamment qui existent. Quelqu'un a fait remarquer plus haut qu'Emacs pouvait être utilise comme vi(m). Personnellement ce que j'apprécie dans vi (a la base), c'est sa légèreté, et sa simplicité d'utilisation (en tout cas plus simple qu'Emacs et ces c-x M etc ....). Pour éditer rapidement un fichier de conf ou un fichier texte de base c'est tout bon, mais pour faire du developpement y a quad même des IDE mieux adaptés.

    • [^] # Re: quand même je me pose une quuestion ....

      Posté par  . Évalué à 6.


      mais pour faire du developpement y a quad même des IDE mieux adaptés.


      < Ma vie >

      Je développe en ruby, perl, php, ... selon les besoins (mais je fais surtout du ruby pour le moment) et je n'ai encore rien trouvé de mieux et de plus simple que vim pour travailler.

      Vim me permet de garder le même environement de travail quelque soit le langage utilisé et quand on connait bien vim, c'est largement aussi puissant que la plupart des IDE.

      < / Ma vie >

    • [^] # Re: quand même je me pose une quuestion ....

      Posté par  . Évalué à 6.

      z'y va l'autre!!! Vim juste bon à éditer un fichier de conf!!!! Tant que tu y es dit que c'est comme Notepad!!! ;-)
      Je te conseille de regarder derrière toi dorénavant quand tu sors dans la rue... ;-)

      • [^] # Re: quand même je me pose une quuestion ....

        Posté par  . Évalué à 2.

        Ce n'est pas exactement ce que je voulais dire :)

        Je voulais faire remarque que vi a l'origine est un éditeur léger et puissant, et que vim par son coté "usine a gaz" commence à rendre lourd l'ensemble, c'est tout. Et pour répondre au post précédent (x)emacs par exemple a l'air de fournir un mode d'édition à la vi. Donc, quitte à utiliser une usine à gaz, pourquoi ne pas l'utiliser? ^Je trouve simplement que c'est un "gachis" de ressources (de mon point de vue - après si certains en sont contents, tant mieux).

        • [^] # Re: quand même je me pose une quuestion ....

          Posté par  . Évalué à 4.

          Je voulais faire remarque que vi a l'origine est un éditeur léger et puissant, et que vim par son coté "usine a gaz" commence à rendre lourd l'ensemble, c'est tout.

          Je ne vois pas où est le gachis? La simplicité de vi te plait? Elle est toujours présente de façon identique dans vim. Je ne vois pas où est la lourdeur? Tu veux un éditeur qui bastonne un peu plus avec des fonctions avancées pour faire du dev ou de l'édition au kilomètre, c'est aussi possible avec vim et toujours de manière efficace. C'est un peu comme si avec un seul véhicule tu pouvais passer du vélo à la formule 1 en fonction de tes besoins du moment. C'est ti pas magnifique?
          Pourquoi utiliser 2 éditeurs alors qu'un seul fait très bien les deux?

          Et pour répondre au post précédent (x)emacs par exemple a l'air de fournir un mode d'édition à la vi. Donc, quitte à utiliser une usine à gaz, pourquoi ne pas l'utiliser?

          J'ai utilisé xemacs pendant 1 an avant de découvrir vim (depuis 3 ans et demi) et je n'ai pas envie d'y retourner. C'est plus lourd que vim plus long à lancer, tu risques la fouloure du doigt à chaque raccourcis clavier ;-)
          Je ne sais pas si il existe un mode vi pour emacs mais il existe vimacs qui est un mode emacs pour vim...

          • [^] # Re: quand même je me pose une quuestion ....

            Posté par  . Évalué à 1.

            C'est un peu comme si avec un seul véhicule tu pouvais passer du vélo à la formule 1 en fonction de tes besoins du moment. C'est ti pas magnifique?
            Si sauf qu'une formile1 ne rentre pas dans mon appart tandis qu'un vélo, oui.

            Je ne sais pas si il existe un mode vi pour emacs
            D'après les posts plus haut, oui.

            Il me semble que vim est l'éditeur par défaut de beaucoup de distribution non? Ca m'étonne donc pas qu'une Debian prend plus de 400 Mo pour une installation minimale alors ....

            • [^] # Re: quand même je me pose une quuestion ....

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

              Ouéééé une image à base de voitures.
              Bon, donc vi est un vélo, vim est une formule 1 (je ne suis pas trop d'accord, vim est capable de franchir les ralentisseurs). Alors emacs doit être un hummer, lent moche et impossible à utiliser en ville.

              Sur ma debian, vim (vim-full + vim-gui+vim-common) prend 3 Mo. Installer emacs demande 42 Mo... Mais cependant, c'est vrai que je considère vim comme un poil trop gros...

              plouf

            • [^] # Re: quand même je me pose une quuestion ....

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

              Sauf que je crois que c'est nvi l'editeur par défaut sous debian. En effet, nvi est plus proche des bogues de l'original que vim. Mais j'ai vu passer sur une liste debian qu'ils envisagent de remplacer nvi par vim-tiny.

              Je ne parle pas d'une debian où tu installes tout. Je parle d'une debian minimale. Si tu installes vim, il prend la place de nvi par défaut car il a une priorité plus élevée (voir le système des update-alternative de debian pour cela).

        • [^] # Re: quand même je me pose une quuestion ....

          Posté par  . Évalué à 1.

          Sur des machines un minimum puissantes, on ne sent pas la difference entre le chargement de vi et vim. Et malgré cela, il y a toujours plus de fonctionnalités utiles. (à ce propos, vim fait-il le café ?)

          D'autre part lorsque je passe sous un autre éditeur je perds pas mal de repères, le "ESC :w" ne fonctionnant pas par exemple.

          Donc, quitte à utiliser une usine à gaz, pourquoi ne pas l'utiliser


          <caricature>
          Et puis tant qu'a utiliser une usine a gaz pour développer mes petits projets de rien du tout, je vais installer windows et l'IDE de microsoft et là je vais m'amuser.
          </caricature>

          • [^] # Re: quand même je me pose une quuestion ....

            Posté par  . Évalué à 3.

            Et puis tant qu'a utiliser une usine a gaz pour développer mes petits projets de rien du tout, je vais installer windows et l'IDE de microsoft et là je vais m'amuser.

            Java+eclipse suffisent amplement :)

Suivre le flux des commentaires

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