Journal Neovim : vim's rebirth for the 21st century

Posté par . Licence CC by-sa
31
25
fév.
2014
Ce journal a été promu en dépêche : Neovim : une refonte de vim pour le 21è siècle.

Context

Vim, le fameux éditeur de texte, est un logiciel ayant plus de 20 ans, qui contient environ 300 000 lignes de code de vieux C effrayant, que peut de gens comprennent.

Le mainteneur (unique ?) de vim, Bram Moolenaar, refuse de factoriser certaines parties du code, et est très prudent avant d'accepter des patchs, car c'est lui qui devra en assurer la maintenance.

Conséquence de tout ça : vim est très dépendant d'une seule personne, et évolue très lentement.

Neovim

Neovim est un fork de vim très récent (fin janvier 2014), qui a pour objectif premier de simplifier la maintenance de vim :

  • modernisation de système de compilation : utilisation de cmake ;
  • suppression du code assurant la compatibilité avec de vieux systèmes ;
  • utilisation d'une bibliothèque externe (libuv) pour s'abstraire des différentes entre les systèmes d'exploitations ;
  • factorisation « agressive » du code ;
  • meilleur séparation du code entre différents développeurs.

Par la suite, un nouveau système de plugins est prévu, ainsi que la possibilité de pouvoir créer plus facilement des interfaces graphiques (à la manière des plugins).

Pour les utilisateurs d'Arch Linux, neovim est disponible dans aur. La configuration et les plugins de vim sont compatibles (.neovimrc et .neovim/).

Une campagne de financement participatif est en cours : https://www.bountysource.com/fundraisers/539-neovim-first-iteration
Elle a déjà atteint le premier objectif de 10 000 $ en à peine 48h00 !

Pour l'utilisateur final, neovim n'a actuellement pas d'intérêt particulier, mais il peut devenir à terme très intéressant :

  • développement plus pérenne (ne repose pas sur une seule personne) ;
  • correction de bugs et nouvelles fonctionnalités plus vite intégrées.

Site du projet (casi vide) : http://neovim.org/
neovim sur github : https://github.com/neovim/neovim/

  • # La réponse de Bram Moolenaar

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

    https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8

    It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly?
    Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users.

    • [^] # Re: La réponse de Bram Moolenaar

      Posté par (page perso) . Évalué à 6. Dernière modification le 26/02/14 à 08:10.

      It's much better to improve what we have.

      Mais si pour ça il faut refactoriser car le code est trop bordélique et que si on améliore sans refactoriser on y passe 10x plus de temps, et qu'en même temps l'idée même de refactoriser n'est pas acceptée, je comprend parfaitement le fork face à cette réponse qui ne veut pas voir le problème.

      new bugs introduced

      Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).

      what's the gain for the end user exactly?

      Plus de fonctionnalités implémentées car les développeurs seront alors libérés d'un code qui est devenu trop complexe au fil des ans et n'est plus adapté?

      • [^] # Re: La réponse de Bram Moolenaar

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

        Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).

        En parlant de ça, j'ai un bug qui date d'au moins plusieurs années (mais peut-être c'est ma configuration). Quand je découpe la fenêtre en deux, si j'entame un commentaire sur la fenêtre du haut, la fenêtre du bas devient 100% en couleur de commentaire (normal puisque j'ai pas terminé le commentaire). Mais quand je termine d'écrire mon commentaire, la fenêtre du bas garde la couleur de commentaire ce qui est assez énervant.

        l'azerty est ce que subversion est aux SCMs

      • [^] # Re: La réponse de Bram Moolenaar

        Posté par . Évalué à 9.

        Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).

        Pour éviter d'introduire des bugs lors de refactorisation, il est possible de créer des tests aussi. C'est d'ailleurs intéressant parce qu'on peut se rendre compte que l'ancienne version est très difficile à tester alors que la nouvelle, en plus des gains, en lisibilité/performance/fonctionnalité/sécurité est plus facile à tester.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: La réponse de Bram Moolenaar

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

          Je me suis renseigné un peu sur le projet. Ayant eu la naïveté de vouloir coder un clone de Vim par le passé ( Yzis ) et ayant tenté plusieurs projets d'intégration de Vim (KVim et autres), j'étais curieux de voir ce que ça donne.

          Rappelons quand même que:

          • Vim est un très bon éditeur, globalement plutôt stable, très portable
          • des tonnes de plugin pour faire plein de trucs sont dispo. C'est pour ça que l'auteur veut maintenir la compatibilité avec les plugin
          • Bram le maintient avec succès depuis des années.

          Les points négatifs:

          • la base de code de Vim est infame. Comme le note Thiago l'auteur du fork, il est bourré de ifdef pour chaque fonctionnalité alors que dans les faits, les distrib vont surtout faire toutes les fonctionnalités ou un vim minimal mais vont très rarement s'amuser à ajouter/enlever une fonctionnalité particulière.
          • la couche graphique s'intègre très mal. Il n'y a pas de boucle d'évènement dans vim, il est toujours basé sur le principe "j'attends un caractère et je le traite". Ca rend très compliqué tout un tas d'évolutions qui pourraient apporter des trucs sympa.
          • le code mélange allègrement des variables globales, des allocations d'éléments de listes en plein milieu d'une fonctionnalité élaborée. Faut s'acrocher. Rien qu'utiliser une lib générale pour gérer des listes comme glib simplifierai significativement le code.
          • Bram est très lent à intégrer des patch. J'ai déjà proposé des patchs triviaux sur des trucs visiblement mal fini qui ne sont pas intégrés parce que globalement, Bram s'en fout de cette partie-là de Vim.
          • la direction générale de Vim est plutôt incohérente. On sent que Bram préferait qu'il n'y ai finalement aucune nouvelle fonctionnalité, mais des gens lui proposent des patchs à tour de bras pour plein de trucs avec lesquels il n'est pas à l'aise. Du coup, ça s'intègre mais de façon sporadique. On sent pas pas le "Non, je mettrai rien de nouveau", ou le "oui, OK pour intégrer des nouveaux trucs mais sous telles et telles conditions". Ca reste un arbitrage un peu flou. C'est là qu'on mesure mieux le talent de leadership de Linus.
          • Pour illustrer l'esprit, il y a encore deux ou trois ans, Bram publiait encore des patchs sur la mailing liste et des outils horribles tels que CVS, SVN, HG ou GIT ou autres étaient proscrits.
          • pour citer des gros points faibles :

            • c'est dur de faire évoluer le GUI de vim, parce que l'architecture de Vim se prête très mal à un GUI moderne
            • le langage de script maison, c'est sympa mais ça commence sérieusement à montrer ses limites
            • Vim ne peut rien gérer en asynchrone. Pour tout un tas de plugin, c'est vraiment génant.
            • Si vous aviez le projet comme moi d'embarquer Vim en tant que composant dans un autre logiciel (IDE ou autre), c'est en fait infaisable à cause de la nature très monolithique de Vim et de l'absence de boucle d'évenement.

          Pour moi, Vim est un très bon éditeur, qui commence à montrer son age. Les pratiques de développements d'un autre age ne tiennent plus la route face à la popularité et aux nouveaux enjeux d'un éditeur moderne. C'est un peu la FSF contre Github.

          Donc un rafraichissement tel que celui proposé me semble tout à fait louable, avec un bon potentiel d'amélioration. Après, il ne faut pas sous-estimer la tâche. Vim est très gros, maintenir un fork de cette taille est un boulot monstrueux, et ce n'est pas sur qu'une équipe même motivée arrive à faire le travail de fond que fait Bram depuis des lustres.

          J'ai regardé un peu le CV de Thiago de Arruda qui est l'auteur de cette initiative. C'est pas un manchot, il a déjà codé des trucs intéressants avec Vim, mais globalement, il est loin d'avoir donné la preuve qu'il est à la hauteur de l'enjeu. Forker un gros projet, c'est très difficile à tenir dans le temps. Les forks réussis qui durent sont extrèmement rares, il faut l'adhésion d'une partie de l'équipe de développement du coeur pour que ça réussisse. Sinon, ça retombe au bout de quelques mois.

          En tout cas, bonne initiative. Ca me permettra peut-être de lacher SublimeText pour revenir à Vim…

          • [^] # Re: La réponse de Bram Moolenaar

            Posté par . Évalué à 2.

            Vim est très gros, maintenir un fork de cette taille est un boulot monstrueux

            Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème? Visiblement, il faut avoir le cœur bien accroché pour aller voir le code, on dirait les avertissements vers les liens des vidéos de terroristes qui égorgent leurs otages à la machette rouillée. Donc j'avoue ne pas être assez courageux pour aller zyeuter les entrailles de vim, mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature. Si le fork se concentre sur un système de plug-ins, il sera peut-être possible d'avoir une base saine minimaliste autour de laquelle pourront se greffer des extensions qui n'auront pas à être maintenues par le projet cœur. Enfin c'est ce que j'ai cru comprendre, vu de loin.

            • [^] # Re: La réponse de Bram Moolenaar

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

              Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème?

              mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature.

              Oui et non. De fait, le fork va réduire le nombre de lignes de code en s'appuyant sur des lib existantes, en supprimant des fonctionnalités inusitées (la comapbilité old-vi est elle encore une fonctionnalité ?).

              Une restructuration de la base de code permettra de séparer mieux les GUI et limitera le mélange des genres.

              Après, il ne faut pas se leurrer, Vim reste un gros logiciel. Il y a un langage de script, un moteur de coloration syntaxique, un gestionnaire de terminal, la gestion de macros, de registres, des 5 modes d'éditions différents, de lancer des compilations, des bindings pour différents langages (Python, …).

              Tout ça ne va pas disparaitre et va rester coton à maintenir !

          • [^] # Re: La réponse de Bram Moolenaar

            Posté par (page perso) . Évalué à 4. Dernière modification le 26/02/14 à 11:08.

            il est bourré de ifdef pour chaque fonctionnalité alors que dans les faits, les distrib vont surtout faire toutes les fonctionnalités ou un vim minimal mais vont très rarement s'amuser à ajouter/enlever une fonctionnalité particulière.

            Les ifdef sont rarement pour les distribs.
            Perso, j'ai une chiée de ifdef dont aucun pour les distribs, mais pour des clients qui veulent de la perf/du gain d'espace/ne pas dépendre d'une lib/autre sans pour autant perdre la fonctionnalité qui les interesse.
            Supprimer les ifdef est enlever une fonctionnalité (pas qui t'interesse, mais qui itneresse une autre personne). Donc pas terrible.

            Les forks réussis qui durent sont extrèmement rares,

            Ca arrive, et ça arrive même que la FSF accepte l'idée qu'elle a grandement merdé dans son conservatisme (OK, c'est rare! :) )

            • [^] # Re: La réponse de Bram Moolenaar

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

              Les ifdef peuvent avoir une utilité pour un logiciel qui doit en effet se décliner en N versions différentes.

              Est-ce le cas de Vim ? Je suis loin d'en être persuadé. Il y a bien un besoin entre un Vim minimaliste pour des plate-formes minimalistes et un Vim bouffi pour ceux qui ne regardent pas à la taille. Mais choisir individuellement entre avoir le support des split verticaux, des jumplist, et autres joyeusetés, est-ce que ça a un sens.

              Pour ceux qui veulent voir à quoi ça ressemble, c'est:
              https://code.google.com/p/vim/source/browse/src/feature.h

              Supprimer les ifdef est enlever une fonctionnalité (pas qui t'interesse, mais qui itneresse une autre personne). Donc pas terrible.

              En l'occurence, il supprime la possibilité de supprimer une fonctionnalité en l'incluant automatiquement de base.

              J'ai fait le compte vite-fait, il y a 110 feature différentes qui peuvent être activées ou désactivées. Question subsidiaire, qui teste les 2110 = 1298074214633706907132624082305024 combinaisons qui en resultent ? On est clairement dans un truc incohérent.

              Dans les faits, certaines de ces fonctionnalités correspondent à des fonctionnalités spécifiques à des plate-formes. Mais au lieu d'avoir une couche de portabilité claire et des fichiers sources isolés, tout est en bazar dans la même base de code, sans permettre de distinguer facilement ce qui appartient à quoi.

              Les forks réussis qui durent sont extrèmement rares,
              Ca arrive, et ça arrive même

              Une des clés me semble être l'adhésion d'une partie de l'équipe de développement principale.

          • [^] # Re: La réponse de Bram Moolenaar

            Posté par . Évalué à 3.

            le langage de script maison, c'est sympa mais ça commence sérieusement à montrer ses limites

            C'est vrai qu'utiliser quelque chose comme lua serait cool. Ça casse la compatibilité mais ça permet de ne plus se soucier de maintenir un langage en plus. Je parle de lua parce qu'il est fait pour ça, comme guile.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: La réponse de Bram Moolenaar

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

              Pour l'avoir tenté, lua ne serait pas mon premier choix, même si c'est celui qui a été fait par neovim.

              Ce qui est cool, c'est d'avoir un langage de script prêt à l'emploi, documenté, avec même un jit qui existe. Les gros incovénients de lua, c'est:

              • le paradigme de programmation est plutôt original par rapport à ce qu'on connait: pas de classes mais une émulation complexe est possible mais va vite être potentiellement foireuse
              • pas de compatibilité assurée entre les différentes versions de lua. Et ça, ça fait mal. Il n'est même pas possible d'écrire un programme qui soit à la fois compatible entre lua 5.0 5.1 et 5.2 . Les syntaxes diffèrent de manière incompatibles…
              • [^] # Re: La réponse de Bram Moolenaar

                Posté par . Évalué à 2.

                Quelles sont les autres alternatives ?

                Si on plonge un petit peu dans l'histoire, on peut retourner à l'époque où Gnome cherchait un langage de script à mettre en avant pour la version 3, afin d'éviter d'avoir 150 langages comme c'était le cas dans Gnome 2. C'est Javascript qui a été choisi, car l'un des critères principaux était le fait que le langage soit dynamique et ne vienne pas avec sa propre plateforme (comme python, perl, etc). D'autres langages qui correspondent à ces critères sont scheme/lisp et lua, mais en fait ça écarte de facto la plupart des langages "barbus" habituels comme python, ruby ou perl…

                Bon, en pratique les applications écrites en python n'ont pas été réécrites pour autant…

                • [^] # Re: La réponse de Bram Moolenaar

                  Posté par . Évalué à 2.

                  On peut regarder un peu plus loin qu'un seul projet aussi, hein ?

                  • firefox : C++/js (avec une grosse orientation vers js maintenant)
                  • gimp : scheme/python
                  • gcc : lisp (via MELT par exemple)
                  • emacs : lisp
                  • awesome : lua
                  • xmonad : haskell
                  • wmii : shell (en fait ça utilise un pseudo système de fichiers dérivé de plan 9)

                  Et il doit y en avoir d'autres. Note qu'il semble admit actuellement, qu'il vaut mieux étendre plutôt que permettre des extensions (par exemple). Ça me semblerais intéressant pour un dérivé de vi.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: La réponse de Bram Moolenaar

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

                    • Qt: javascript

                    Honnêtement, ça m'arrache le c** de dire ça mais je pense que javascript est le meilleur langage de script qui réponde à ces contraintes:

                    • raisonnablement populaire
                    • facile à apprendre pour que n'importe qui crache un script vite-fait
                    • corollaire: ressemble à un langage existant genre C/C++/Java. Exit donc tous les choix en dehors de Python
                    • portable
                    • raisonnablement facile à embarquer (Python brille pas ici mais il s'en sort)
                    • relativement compact (Python, oups… mais il fait des progrès il parait)

                    Je pense que c'est pour toutes ces raisons que Qt a finalement choisi Javascript bien que ce soit pas un choix évident.

                    • [^] # Re: La réponse de Bram Moolenaar

                      Posté par . Évalué à 2.

                      corollaire: ressemble à un langage existant genre C/C++/Java. Exit donc tous les choix en dehors de Python

                      Là tu parle de la syntaxe, parce que le modèle objet de python est plus proches de C++/Java que js.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: La réponse de Bram Moolenaar

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

                        C'est de moins en moins vrai avec les dernières constructions du langage, mais pendant longtemps, quand tu voyais un programme Python et que tu connaissais le C,C++,Java,VB ou C#, tu comprenais ce que faisais le programme.

                • [^] # Re: La réponse de Bram Moolenaar

                  Posté par . Évalué à 1.

                  Quelles sont les autres alternatives ?

                  Les alternatives existent, même si ce n'est pas forcément mainstream.
                  Par exemple (je ne me suis pas amusé avec ce langage donc je ne sais pas ce qu'il vaut), Code::Blocks utilise squirrel.

              • [^] # Re: La réponse de Bram Moolenaar

                Posté par . Évalué à 2.

                Je n'ai pas était très choqué par la programmation en lua (mais j'en ai peut être pas fait des masses). Par contre la rupture de compatibilité est à mon avis assez importante et c'est probablement ce qui me fera changer de gestionnaire de fenêtre quand je mettrais à jour mon awesome (disons que c'est la goute d'eau, j'ai envie de passer à xmonad depuis longtemps maintenant).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: La réponse de Bram Moolenaar

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

                  c'est probablement ce qui me fera changer de gestionnaire de fenêtre
                  quand je mettrais à jour mon awesome

                  Tiens, c'est ce qui m'a fait passer à i3. Après une heure d'essais infructueux en lua, j'ai laissé tombé; la documentation n'était pas très à jour et je ne comprenait plus rien.

                  i3 fonctionne sans rien configurer.

                  Mais je ré-essaierai, il y a quelques petites choses qui me manquent, comme le chti menu et le basculement dans les styles. Avec I3, ça devient vite un puzzle ou un taquin.

                  • [^] # Re: La réponse de Bram Moolenaar

                    Posté par . Évalué à 3.

                    Je ne pense pas que changer la conf' sera vraiment bloquant pour moi (c'est le langage qui a une rupture de compatibilité pas la manière de gérer la conf' en elle même (de ce que j'ai compris)). Mais xmonad me fait de l'œil depuis pas mal de temps, il faut juste que je trouve la motivation pour m'y mettre sérieusement (il est plus rustique qu'awesome).

                    i3 j'ai jamais vraiment adhéré, je ne retouche presque jamais mes clients, je laisse ça aux layouts et je me contente de changer de layout en fonction de mon besoin. C'est comme ça que j'apprécie d'utiliser ma machine et c'est pas un comportement prévu pour i3.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: La réponse de Bram Moolenaar

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

                      je ne pense pas que changer la conf'
                      sera vraiment bloquant pour moi

                      Ce n'était pas tant la configuration, mais le fait d'avoir à la refaire et de ne pas y être arrivé rapidement. Ça vexe puis ça fâche.

                      je laisse ça aux layouts et je me contente de changer de layout en fonction de mon besoin

                      C'est ce que voulais dire, les dispositions pré-définies par awesome manquent avec i3.

                      • [^] # Re: La réponse de Bram Moolenaar

                        Posté par . Évalué à 1.

                        C'est sûr, c'est le genre de fonctionnalités qui me manquent personnellement, même sans les avoir essayées. J'ai pu voir des screen qui m'ont fait comprendre l'idée, rien de plus, mais… c'est séduisant tout de même.

                        Pour le coup, à part que ces layouts sont faits via lua, comment ça marche, en gros? Je me dis que quelque part, peut-être qu'avec des scripts exploitants les IPC d'i3… enfin, je ne sais pas, mais peut-être qu'il y aurait moyen de faire un truc qui sois moins pénible que refaire complètement le layout à chaque démarrage de la machine. Donc, comment qu'ils font, en face? ( parce que j'aime énormément l'idée du fichier de config simple, malgré tout… )

                        • [^] # Re: La réponse de Bram Moolenaar

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

                          Les dispositions ne sont pas faites en Lua, Awesome fournit une collection de dispositions, accessibles en lua pour peaufiner, ou pour définir une disposition par défaut pour chaque espace.
                          Du coup, on en arrive à toujours charger les logiciels connus dans un espace particulier (cela se fait aussi en lua), qui va tout organiser tout seul.

                          C'est particulièrement intéressant lorsque l'on utilise majoritairement des outils qui tournent dans un xterm.

                          les dispositions sont là.

                          • [^] # Re: La réponse de Bram Moolenaar

                            Posté par . Évalué à 1.

                            En fait, j'ai fini par faire des scripts shell pour placer à peu près. Ca bug à cause du temps, mais ça marchotte. Pour le coup, j'ai posé la question sur la ml d'i3 au sujet de comment résoudre ces bugs, et on m'a répondu que la prochaine version inclue un mécanisme de layout, qui résout donc ce manque de fonctionnalité.
                            A condition d'utiliser le dépôt git, bien entendu.

                            A voir, donc.

                  • [^] # Re: La réponse de Bram Moolenaar

                    Posté par . Évalué à 4.

                    Ça serait cool un rubix cube en dimension N. Pour les vrais hommes.

                    Please do not feed the trolls

              • [^] # Re: La réponse de Bram Moolenaar

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

                le paradigme de programmation est plutôt original par rapport à ce qu'on connait: pas de classes mais une émulation complexe est possible mais va vite être potentiellement foireuse*

                Pas de classes, je suis d'accord. Mais l'émulation ne me semble pas tellement complexe, voir même plutôt relativement simple et claire (et pas de "magie" justement).

                pas de compatibilité assurée entre les différentes versions de lua. Et ça, ça fait mal. Il n'est même pas possible d'écrire un programme qui soit à la fois compatible entre lua 5.0 5.1 et 5.2 . Les syntaxes diffèrent de manière incompatibles…

                La numérotation Lua est étrange. Si on regarder l'historique:
                - 5.0 : 2003
                - 5.1 : 2006
                - 5.2 : 2011

                En référence à ces valeurs, je ne suis pas sûr que lua s'en tire plus mal que d'autres. (2003, c'est Python 2.2 par exemple).

                • [^] # Re: La réponse de Bram Moolenaar

                  Posté par . Évalué à 3.

                  En référence à ces valeurs, je ne suis pas sûr que lua s'en tire plus mal que d'autres. (2003, c'est Python 2.2 par exemple).

                  Je n'en suis pas si sûr. Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7, même si l'inverse n'est pas forcément vrai.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: La réponse de Bram Moolenaar

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

                    Je n'en suis pas si sûr. Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7, même si l'inverse n'est pas forcément vrai.

                    J'aimerai bien voir ça quand même :) J'ai jeté un coup d'oeil aux changelog entre 2.2 et 2.7, et il y'a peut être des programmes avec la même sémantique, mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner. Par exemple, None et yield sont des noms de variable valide en Python 2.2.

                    Bien sûr, on ne parle évidemment pas de Python 3.x, on serait méchant :).

                    • [^] # Re: La réponse de Bram Moolenaar

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

                      mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner.

                      Je serai curieux de voir ça. Python 2 est globalement rétrocompatible.

                      Du côté de mon expérience personelle:

                      • j'ai appris à coder en Python 1.5.2 et j'ai codé longtemps avec un interpréteur 2.2 sans rien connaitre des nouveautés de Python, sans que ça me pète à la gueule
                      • lors de nos migrations internes au boulot 2.2 -> 2.5 et 2.5 -> 2.7, on a rencontré absolument aucun problème.
                      • je maintiens un programme qui tourne sur Python 2.5 à 3.4 toutes versions comprises, avec une seule base de code.

                      Par exemple, None et yield sont des noms de variable valide en Python 2.2.

                      Là, bon évidemment! Mais tu assignes souvent une valeur à None, même en Python 2.2 ? J'aimerai bien voir un programmer marcher avec None = 1, juste pour rire.

                      Il reste donc les nouveaux mot-clés: yield , with et probablement un ou deux autres.

                      • [^] # Re: La réponse de Bram Moolenaar

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

                        Je n'ai jamais écrit de code en Python 2.2.

                        Ça ne me choque pas de définir une constante None à 0, et d'utiliser cette constante symbolique plutôt qu'un entier. C'est exactement ce qu'on fait avec NULL.

                        raise "foo" est valide jusqu'à 2.6 et renvoie un TypeError depuis 2.6. Je ne vais sérieusement pas énuméré tous les "Porting your code to Python 2.x" de la documentation pour prouver que l'assertion "Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7" est fausse. Un contre-exemple suffit.

                        Python 2 est globalement rétrocompatible.

                        Globalement, globalement:) Lua est globalement compatible à quelques exceptions près :).

                        Je maintiens un programme qui tourne sur Python 2.5 à 3.4 toutes versions comprises, avec une seule base de code.

                        Je ne dis pas que c'est impossible.
                        Juste le traitement des u"foo" est chiant, vu que c'est valide en 2.{5, 6, 7}, 3.{3, 4}, mais pas en 3.{0, 1, 2}. Mais on peut toujours se débrouiller.
                        Le nom des imports change, mais on peut se débrouiller aussi (avec des raise / except).
                        Il ne faut juste pas dire que c'est "out of the box", je ne fais pas attention, et ça marche parfaitement entre 2.5 et 3.4. Là, personnellement, je n'y crois pas.

                    • [^] # Re: La réponse de Bram Moolenaar

                      Posté par . Évalué à 2.

                      Par exemple, None et yield sont des noms de variable valide en Python 2.2.

                      Ça a été prévu. À partir de la 2.1 tu peux faire ça :

                      import __future__

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: La réponse de Bram Moolenaar

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

                    Le langage ne se résume pas aux constructions syntaxiques, les différents modules de base de Python évoluent fortement d'une version à l'autre, ce qui casse tout programme qu'on veut faire évoluer.

            • [^] # Re: La réponse de Bram Moolenaar

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

              Je pense qu'il faudrait un langage fait pour la gestion de texte, de grammaire.
              Code Worker est par exemple un langage pensé pour gérer du texte. Ce pourrait être une piste intéressante pour un langage maison.

              Le problème des langages cités est qu'ils ne sont pas orientés gestion du texte. On parle de scripts pour un éditeur texte, ici…

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: La réponse de Bram Moolenaar

                Posté par . Évalué à 1.

                Considérant que prolog est fait pour les linguistes, j'imagine que ce serait le genre de langages que tu aimerais voir? xD

                • [^] # Re: La réponse de Bram Moolenaar

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

                  Aimerais, ce n'est pas la question.
                  La question est de fournir un éditeur qui ait en natif les outils pour faire un assistant de programmation, un peu comme Eclipse, mais en moins lourd et sans Java.
                  Le but des script est d'analyser du texte, faire de la coloration syntaxique, analyser grammaticalement le code, aller chercher de la doc, intégrer tous les fichiers d'un projets, gérer un gestionnaire de version, etc..

                  Il faut donc un langage spécifique au traitement du texte ET généraliste (pour ne pas empêcher un auteur d'inventer une idée farfelue mais utile). CodeWorker est intéressant car c'est un langage qui intègre la possibilité de déclarer des grammaire BNF en natif.
                  En plus c'est un langage qui n'est pas trop distant de ce que les gens connaissent.
                  Faire un langage, c'est énormément de travail, je sais de quoi je parle, ce langage étant une bonne base, il pourrait être intéressant d'en partir.

                  Mais on peut toujours l'intégrer à NeoVim ;-)

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: La réponse de Bram Moolenaar

                    Posté par . Évalué à 2.

                    car c'est un langage qui intègre la possibilité de déclarer des grammaire BNF en natif.

                    Ha oui en effet! J'admets être parti à la déconnade ( j'ai essayé prolog… je n'ai pas vraiment réussi à faire grand chose avec malheureusement ), mais un langage qui intègre les bnf dans le langage à un potentiel évident.
                    Comme quoi, parfois c'est utile de déconner :)

  • # Charité

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

    Mouais..

    Détourner des utilisateurs d'un CharityWare pour un fonds différent c'est très moyen..

    Bram sait faire des merveilles en Uganda avec 10.000USD.

    • [^] # Re: Charité

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

      Mais Bram sait-il faire des merveilles sur sa codebase avec 10.000USD ? ;-)

    • [^] # Re: Charité

      Posté par . Évalué à 10.

      C'est ce que j'ai pensé aussi.

      C'est honteux de forker un logiciel qui incite à donner pour les enfants de l'Ouganda.

      À peine réussi-t-on à les protéger du péril des dangereux pervers homosexuels qu'on leur coupe les vivres.

      Il est évident que ce coup bas est une émanation du looby sataniste LGBT.

      Pour aller au paradis, refusez ce fork.

      CAPTCHA: TINC.

      • [^] # Re: Charité

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

        Apparemment, il y a une société des ostéopathes qui a contribué pour 42 % de ces dons, ils en avaient marre de voir des gens s'abîmer les doigts avec emacs.

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

        • [^] # Re: Charité

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

          ils en avaient marre de voir des gens s'abîmer les doigts avec emacs.

          Ça aurait été plus simple de leur faire remarquer qu'ils ont deux mains!

    • [^] # Re: Charité

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

      Bah c'est surtout demander 10000$ pour 2 mois de boulot en étant localisé au Brésil…
      Le développeur de git-annex demandait 15000$ pour un an de boulot en étant basé aux états unis. Bon, l'exemple est extrême, mais 5000$ par mois même s'il faut décompter les charges, pour faire le ménage et mettre en place le système de plugins, ça me parait un peu élevé.

      • [^] # Re: Charité

        Posté par . Évalué à 10.

        Maintenant que le bitcoin est en train de s'effondrer, c'est peut être le prochain moyen de se faire de l'argent facilement.

        1/Tu bosses à fond sur un projet que tu aimes bien (ou que tu n'aimes pas, ça n'a pas d'importance) pendant deux semaines non stop.
        2/Tu écris un article de blog disant que c'est tous des salauds les bénévoles du projet, ils n'ont acceptés que la moité de tes patches. Bien sûr il ne faut pas de commentaires dans le blog. Les admins du projets risqueraient de venir dire que tes patches sont sales ou qu'ils n'avaient pas de temps, mais que ça sera bientôt intégré.
        3/Tu lances une campagne kickstarter en promettant plus de réactivité dans le traitement de bugs, dans l'ajout de features. Que ta version sera deux fois plus réactive et plus sikioure et plus bugproof avec deux fois moins de lignes de codes parce que tu vas tout refactoriser et qu'en plus il y aura de belles icônes.
        Tu factures détailles une liste de tâches qui devrait prendre 6 mois et tu le factures au prix d'un an de travail au salaire US + charges etc (alors que tu habites au portugal).
        4/Tu fait du buzz à fond sur les sites de dicaïdeur pressés, les sites de hipsters (ceux qui aiment bien être à l'avant garde de tout), sur touiteur, sur faysbouc, dans les commentaires de bugs du projet en question, etc. Tu inondes. Dénigrez, dénigrez, il restera toujours quelque chose.
        5/Au bout d'un mois tu refais un buzz alarmiste en disant « OMG on n'y arrivera jamais donnez OMAGAD! »

        6/ Profit. Tu as travaillé 2 semaines et tu as 1 an d'argent de poche.

        Même si tu ne gagnes que 3 semaines de salaires tu es déjà gagnant.

        • [^] # Re: Charité

          Posté par . Évalué à 5.

          Même si tu ne gagnes que 3 semaines de salaires tu es déjà gagnant.

          Marche pas ton truc. Le marketing prend plus d'une semaine ;)

          Pour le prix, je ne connais pas le marché du brésil ni leur taux de taxes. Mais 10 minutes sur Google semble dire que c'est pas totalement déconnant. Ca fait 11000 BRL/mois avec 34% + ~15% de taxe, on peut arrondir à 50%. Il reste donc 5500/mois ou 66K/an ce qui semble être dans les fourchettes qu'on trouve sur Glassdoor. Je peux avoir totalement tord et ne demande qu'à me faire corriger par quelqu'un qui connait bien le marché local. Mais à vu de pif c'est payé correctement, voir bien, sans être la folie. Et toi tu bosses pour le smic ?

          • [^] # Re: Charité

            Posté par . Évalué à 10.

            Je peux avoir totalement tord et ne demande qu'à me faire corriger

            tort. De rien.

          • [^] # Re: Charité

            Posté par . Évalué à 2.

            66K BR ~ 28KS. Je ne connais pas le salaire moyen d'un (bon) développeur au Brésil, et c'est l'information qui manque pour savoir si c'est complètement disproportionné ou pas.

            • [^] # Re: Charité

              Posté par . Évalué à 7.

              66K BR ~ 28KS. Je ne connais pas le salaire moyen d'un (bon) développeur au Brésil, et c'est l'information qui manque pour savoir si c'est complètement disproportionné ou pas.

              En général une bonne technique pifométrique est de regarder les salaires d'IBM sur Glassdoor pour les raisons suivantes:

              • Ils sont généralement présent dans suffisamment d'endroits pour pouvoir comparer
              • Ils ont suffisamment d'employés pour avoir un échantillonnage utile (attention quand y'a 3 salaires en général c'est nawak)
              • Le système de band permet de cibler assez facilement les profils. Tu sais qu'a une band correspond une fourchette de salaire. Viser la band 7 ou 8 permet de se donner une idée du salaire moyen pour un "bon" développeur ou un petit manager sans rentrer dans les anomalies de salaire des très bons développeurs.

              Bref en band 7 ça annonce dans les 71K par an pour Rio ou Sao Paulo. Un poste équivalent aux US ça correspond grosso modo à 70-90K.

              Si y'a bien ~34% de taxe avant IR, ce qu'il annonce semble donc pas déconnant pour quelqu'un qui ne connait rien au Brésil…

        • [^] # Re: Charité

          Posté par (page perso) . Évalué à 1. Dernière modification le 26/02/14 à 00:24.

          ou tu demandes $10000 et tu reverses $8000 au développeur d'origine (en ne gardant que $1000 par développeur du fork sur les deux mois, ce serait grand prince).
          Je ne sais pas, je n'ai pas suivi l'affaire…

          Pour la partie graphique, ils re-développent^Wfactorisent vim en C++ pour prendre en compte Qt ?

          • [^] # Re: Charité

            Posté par (page perso) . Évalué à 3. Dernière modification le 26/02/14 à 11:01.

            Pour la partie graphique, ils re-développent^Wfactorisent vim en C++ pour prendre en compte Qt ?

            Non. Il propose de définir une interface entre "vim-core" et les plugins / gui, en json-rpc / msgpack-rpc. Evidemment, on peut toujours critiquer le fait qu'il n'est fait que dessiner à gros trait et n'a pas explicité cette interface, ni evalué le surcoût par rapport à un lien plus direct.

            Ça coute vraiment si cher de lire les liens avant de commenter ? :D

            • [^] # Re: Charité

              Posté par . Évalué à 6.

              Pff, il aurait du choisir dbus ! :)

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Charité

              Posté par (page perso) . Évalué à 3. Dernière modification le 26/02/14 à 13:19.

              Pour la partie graphique, ils re-développent^Wfactorisent vim en C++ pour prendre en compte Qt ?

              $10,000 will allow me to dedicate two months of full time work to this project, which will be enough to implement the following:

              • New, modern multi-platform UI written using qtlua.
              • New curses UI written using luaposix. It will look exactly like vim's terminal UI, but implemented with a high-level language that will greatly simplify maintenance. Not to mention it will let me remove a great deal of code dedicated to handling terminals in the core source.
        • [^] # Re: Charité

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

          La seule faille dans l'histoire est que le gars est freelance et a pas franchement besoin de se taper une réputation de voleur ou d'arnaqueur sur le web…

          • [^] # Re: Charité

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

            On ne sait pas encore s'il a dépensé l'argent en pute et en coke, laissons lui le bénéfice du doute et regardons ce qu'il fait avec :)

            En même temps, je pense qu'il va être bien surveillé le gars :)

  • # Hmmm...

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

    • correction de bugs et nouvelles fonctionnalités plus vite intégrées.

    Personnellement, en 15 ans d'utilisation de vim pour coder, rédiger des mails et autres documents je n'ai jamais rencontré de bug …
    Cet argument est donc légèrement HS ;)

    • [^] # Re: Hmmm...

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

      J'ai déjà vu Vim ralentir à un point insupportable à cause de la coloration syntaxique sur un fichier yaml de même pas 100 lignes. Ok, y avait des clés publique ssh dedans donc des lignes un peu longues, m'enfin.

      Sans coloration, ça passait comme un charme.

      It's a fez. I wear a fez now. Fezes are cool !

      • [^] # Re: Hmmm...

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

        Ce qui est terrible c'est la coloration syntaxique de perl6 (heureusement que je l'utilise que pour m'amuser), mais bon le fichier de coloration fait plus de deux mille lignes donc je me demande si c'est vim, le fichier en question, ou perl6 qui a un problème ;)

        Mais peut-être que ça marche mieux depuis la 7.4 vu qu'il y a eu justement des changements par rapport au moteur de regexp et la coloration syntaxique qui sont supposés être plus rapides maintenant, mais j'ai pas encore testé.

        Sinon, ce qui est vrai c'est qu'avec les lignes trop longues vim n'est pas rapide (genre ouvrir sans faire exprès un fichier binaire ou des choses comme ça), mais c'est rarement un problème je trouve pour les fichier qu'on a réellement besoin d'éditer.

    • [^] # Re: Hmmm...

      Posté par . Évalué à 4.

      Idem pour moi, mais il y a beaucoup de logiciels que j'utilise sans soucis et qui ont un bugtracker long comme le bras.

      Par contre pour ce qui est de la réactivité sur les nouvelles fonctionnalités à intégrer, je suis dubitatif.

      Quelqu'un qui a une utilisation un peu poussée de vim utilise des plugins. Les plugins n'ont plus besoin d'une mise à jour du code du core pour être mis à jour. Un peu comme Firefox quoi.

      Avec de véritables gestionnaires de paquets intégrés à vim (vim-addon-manager/vam) on voit bien la vitesse et la régularité de la mise à jour de certains modules.

    • [^] # Re: Hmmm...

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

      Moi non plus. Ça fait 3 ans que je l'utilise non-stop. Je n'ai pas trouvé la commande pour quitter.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Hmmm...

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

        À noter que cette blague fonctionne bien (voire mieux) avec emacs également.

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

        • [^] # Re: Hmmm...

          Posté par . Évalué à 10.

          Note que ça marche aussi avec GNOME 3.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Hmmm...

      Posté par . Évalué à 3.

      Moi si, avec la coloration syntaxique. J'ai jamais regardé si c'était la faute du fichier de syntaxe ou de vim, mais ça m'arrive de temps en temps.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Hmmm...

        Posté par . Évalué à 1.

        Pareil, de temps en temps elle part en vrille (avec des gros scripts Python). Mais un coup de ctrl+L et elle se remet d'aplomb.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Hmmm...

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

      Personnellement j'ai d'énorme problèmes avec les interfaces graphiques comme gvim ou macvim. Et même dans les terminaux, j'ai des problèmes de rafraichissement, d'affichage tout cassé, de lenteurs, de clignotements…

      Rien de critique, mais on ne peut pas dire que ce soit parfait. Je n'aime pas beaucoup ST, mais c'est vrai qu'avoir une GUI fluide c'est appréciable.

  • # Un nouveau Gnome ?

    Posté par . Évalué à 7.

    Quel sont les objectifs de ce projet ? Passage à CMake, suppression de fonctionnalités et ne même pas régler le problème du chemin des fichiers de configuration (car il existe un standard pour ça).
    Ce projet est mort avant même d’être né.

    • [^] # Re: Un nouveau Gnome ?

      Posté par . Évalué à 6.

      Peut etre que l'avantage de neovim c'est que tu pourra ecrire le patch pour respecter le standard des fichiers de configuration et que le patch soit accepte?

    • [^] # Re: Un nouveau Gnome ?

      Posté par . Évalué à 3.

      Note que c'est un standard freedesktop, donc ça n'a pas beaucoup de sens ailleurs que sur linux (mais je suis d'accord avec toi).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Un nouveau Gnome ?

        Posté par . Évalué à 3.

        Hein ? Les standards freedesktop de manière générale ont pas vocation à être spécifiques à linux, que je sache. En particulier celui là.

        • [^] # Re: Un nouveau Gnome ?

          Posté par . Évalué à 2.

          Leurs vocations c'est sympa mais les choses comme dbus et autre n'ont pas vocation à sortir de linux. Donc on peut facilement imaginer qu'il en ai de même pour XDG.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Un nouveau Gnome ?

            Posté par . Évalué à 1.

            C'est pas toi qui m'avait dit qu'« on peut facilement imaginer que… » c'est pas un argument ? :-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Un nouveau Gnome ?

              Posté par . Évalué à 4.

              Bon je vais le refaire. Une norme ça ne vaut rien. Moi demain je peut créer le Michel consortium et créer des normes pour pleins de truc (par exemple pour définir les tailles standards de gâteau). Ce qui fera la différence en entre une norme ISO et ma super MN001 (pour Michel Norme 001) c'est que tout le monde se fout de la mienne alors que tout le monde écoute ISO.

              Donc la question c'est est-ce que freedesktop est écouté par les BSD et autres unix ?
              Ou encore est-ce que freedesktop a la légitimité pour parler des BSD et autres unix ?

              Au vu de son orientation linux et de l'orientation linux-only de ses contributeurs, je ne crois pas.

              Et ce même si XDG est une spec très simple qui n'a besoin de rien pour être déployée sur n'importe quel OS qui supporte HFS donc ce serait dommage de s'en passer.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Un nouveau Gnome ?

                Posté par . Évalué à 4.

                Au vu de son orientation linux et de l'orientation linux-only de ses contributeurs, je ne crois pas

                Mais de qui parle tu ? ;-)

              • [^] # Re: Un nouveau Gnome ?

                Posté par . Évalué à 5.

                XDG-directory ( ou un truc du genre ) n'a pas à être écouté par les dev d'OS, mais les dev d'application.
                Tout OS ( shell, en fait ) qui est capable de gérer un système de fichier, un profil utilisateur et des variables d'environnement supporte cette norme, au final.

              • [^] # Re: Un nouveau Gnome ?

                Posté par . Évalué à 3.

                Tiens je savais pas qu'il y avait une norme ISO pour la taille des gâteaux ;-).

    • [^] # Re: Un nouveau Gnome ?

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

      C'est vrai que mesurer les chances de réussites du projet à l'aune de savoir si il va standardiser les fichiers de config façon freedesktop, c'est une bonne approche !

  • # Evolution

    Posté par . Évalué à 4.

    vim est très dépendant d'une seule personne, et évolue très lentement.

    En même temps à part un système simple (pas un plugin) pour commenter et dé-commenter du code comme le ctrl+m sur gedit, je ne vois pas ce qu'on doit ajouter à vim.
    Ce logiciel a tellement de fonctionnalités, que je l'utilise très régulièrement depuis au moins 3 ans et j'apprends encore des trucs de fous presque tous les mois :-D

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Evolution

      Posté par . Évalué à 10.

      C'est presque une maladie dans l'informatique ça. De considérer qu'un logiciel fini est un logiciel mort.

      Please do not feed the trolls

      • [^] # Re: Evolution

        Posté par . Évalué à 6.

        En même temps j'ai jamais dis ça.

        kentoc'h mervel eget bezan saotred

        • [^] # Re: Evolution

          Posté par . Évalué à 9.

          En même temps il n'a jamais dit que tu l'avais dit.

          • [^] # Re: Evolution

            Posté par . Évalué à 0.

            Bah plus ou moins, c'est tout de même une réponse à mon post. Donc il est naturel de penser que Zylabon a cru que je voulais dire que, étant donné que vim dispose déjà d'une quantité colossale de fonctionnalité il ne devait plus évoluer, hors je pense que vim doit continuer d'évoluer. De plus comme j'aime les forks (la plus part en tout cas) j'espère que néovim apportera un coup de boost et des idées au vim initial.

            kentoc'h mervel eget bezan saotred

      • [^] # Re: Evolution

        Posté par . Évalué à 2.

        d'un autre cote un organisme qui n'evolue pas a de forte chances de disparaitre rapidement d'apres la theorie darwiniene.

        • [^] # Re: Evolution

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

          Ton raisonnement sous-entend que vim est vivant, ce qui est plutôt bon signe pour un logiciel.

        • [^] # Re: Evolution

          Posté par . Évalué à 1. Dernière modification le 26/02/14 à 20:01.

          Pas forcement. L'évolution sert à s'adapter à son environnement. Si une espèce est adaptée et que son environnement ne change pas, elle n'évolue pas.

          L'exemple canonique est celui des Limulidae qui n'ont pratiquement pas évoluée au cours de 500 000 000 dernières années.

          Ça vaut aussi pour les logiciels…

          Please do not feed the trolls

      • [^] # Re: Evolution

        Posté par . Évalué à 1.

        Ben oui c'est un logiciel mort.

        Quid des failles de sécurité ? Des bugs ? (montre moi un seul logiciel parfait !) Des nouveaux usages, nouveaux besoins ?

        Un cas où tout cela ne change pas, ça n'existe pas. Quand le logiciel ne change pas, c'est qu'il est mort.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Evolution

          Posté par . Évalué à 1. Dernière modification le 26/02/14 à 20:53.

          Les bugs (failles de sécurités incluses) sont en nombre fini dans un logiciel quelconque, en les corrigeant un par un sans en introduire de nouveau, au bout d'un moment, il n'y en a plus.

          Des exemples, les logiciels triviaux : cat, rm, echo, cp, true, false…
          Dans les logiciels non triviaux : un bibliothèque pour manipuler des objets X. Si elle est correcte, portable, et si ses performances sont satisfaisantes, pourquoi y toucher ?

          Sinon, des logiciels répondant à un usage précis qui ne change pas, par exemple éditer du texte, les usages n'ont pas changé depuis les les années 60, et les besoins, il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.

          Please do not feed the trolls

          • [^] # Re: Evolution

            Posté par . Évalué à 3. Dernière modification le 26/02/14 à 22:19.

            Les bugs (failles de sécurités incluses) sont en nombre fini dans un logiciel quelconque, en les corrigeant un par un sans en introduire de nouveau, au bout d'un moment, il n'y en a plus.

            Ben non, les "bugs" ça inclut les nouvelles fonctionnalités, les changements quand le compilateur change et que ça impacte ton système de build, ou que tu veux en profiter (par exemple même le support pour C90 n'est pas universel…)

            Et corriger un bug sans en introduire de nouveau, c'est pas si simple que ça…

            Des exemples, les logiciels triviaux : cat, rm, echo, cp, true, false…

            Qui évoluent toujours.

            max-laptop% pacman -Qo /usr/bin/cat
            /usr/bin/cat appartient à coreutils 8.22-2
            max-laptop% pacman -Qi coreutils

            Nom : coreutils
            Version : 8.22-2
            Description : The basic file, shell and text manipulation utilities of
            the GNU operating system
            Architecture : x86_64
            URL : http://www.gnu.org/software/coreutils
            Licences : GPL3
            Groupes : base
            Fournit : --
            Dépend de : glibc pam acl gmp libcap openssl
            Dépendances opt. : --
            Requis par : ca-certificates linux mkinitcpio netctl util-linux
            Optionnel pour : usbutils
            Est en conflit avec : --
            Remplace : --
            Taille installé : 13388,00 KiB
            Paqueteur : Allan McRae allan@archlinux.org
            Compilé le : mar. 17 déc. 2013 02:59:13 CET
            Installé le : lun. 06 janv. 2014 23:26:23 CET
            Motif d’installation : Explicitement installé
            Script d’installation : Oui
            Validé par : Signature

            Dans les logiciels non triviaux : un bibliothèque pour manipuler des objets X. Si elle est correcte, portable, et si ses performances sont satisfaisantes, pourquoi y toucher ?

            Parce qu'on l'utilise et qu'on découvre des bugs ? Qu'on se rend compte que l'API est mauvaise ?
            Qu'on veut cibler une nouvelle plateforme ?

            Les autres logiciels changent, les besoins changent, les compilateurs changent, les langages changent (exemple : passage de Python2 à Python3)…. Tôt ou tard, ton logiciel sera condamné à évoluer.

            Sinon, des logiciels répondant à un usage précis qui ne change pas, par exemple éditer du texte, les usages n'ont pas changé depuis les les années 60

            Ça dépend, si tu édites du code, on a néovim qui sort aujourd'hui encore…

            il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.

            Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, … (pour le code)

            Voire le correcteur ortographique/grammaticale (pour les trucs du genre LibreOffice Writer), l'insertion d'images/tableaux au sein du texte, le support pour l'impression, etc…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Evolution

              Posté par . Évalué à 1. Dernière modification le 26/02/14 à 23:08.

              Pour répondre à la majeure partie de ton commentaire : la conclusion de ta démonstration c'est qu'un logiciel n'est jamais fini, tu ne peux pas l'utiliser comme hypothèse.

              il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.

              Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, … (pour le code)

              J'oublie rien. J'ajoute même que ce genre de truc ne DOIT PAS faire partie du cœur du logiciel, pour pas se retrouver dans 20 ans 150 000 lignes de code mort servant à gérer des langages obsolètes.

              ajout : dans coreutils je doute que ce soient les logiciels triviaux qui subissent les mises à jour.

              Please do not feed the trolls

              • [^] # Re: Evolution

                Posté par . Évalué à 1. Dernière modification le 27/02/14 à 07:21.

                ajout : dans coreutils je doute que ce soient les logiciels triviaux qui subissent les mises à jour.

                Ben si : rm, cp, et ls, au moins.

                J'oublie rien. J'ajoute même que ce genre de truc ne DOIT PAS faire partie du cœur du logiciel, pour pas se retrouver dans 20 ans 150 000 lignes de code mort servant à gérer des langages obsolètes.

                Que cela fasse partie du coeur ou non ne change pas le fait que le logiciel évolue bel et bien constamment quand il est maintenu.

                Pour répondre à la majeure partie de ton commentaire : la conclusion de ta démonstration c'est qu'un logiciel n'est jamais fini, tu ne peux pas l'utiliser comme hypothèse.

                Tu n'y réponds pas du tout. Je t'ai donné des exemples de logiciels triviaux qui évoluent encore, et tu en es encore à dénier la réalité, sans le moindre exemple du contraire.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Evolution

          Posté par . Évalué à 1.

          C’est vrai pour les bloatware.

          Pour les logiciels qui se comptent en centaine de lignes de code, c’est beaucoup moins vrai.

          • [^] # Re: Evolution

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

            Vu qu'on parle de vim ici qui approche le million de ligne de code on est plus proche de ta définition de bloatware.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Evolution

            Posté par . Évalué à 3.

            Ben non. Même les logiciels triviaux évoluent toujours.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Evolution

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

            Pour les logiciels qui se comptent en centaine de lignes de code

            Et y a quoi comme vrai programme qui fait des choses utiles à part hello world, yes et rm qui font quelques centaines de ligne ?

            • [^] # Re: Evolution

              Posté par . Évalué à 3.

              Tu en as des tonnes sur github. La seule difficulté est de les trouver (les trucs de quelques centaines de lignes de code font rarement de la pub en première page sur /.) En auto-pub :

            • [^] # Re: Evolution

              Posté par . Évalué à 2.

              Utile étant très subjectif…
              J'avais à une époque ou je jouais beaucoup aux cartes Magic the gathering, créé un programme qui me permettait de calculer le nombre de terrains de chaque couleur que je devais mettre dans mon jeu pour optimiser mes chances de ne pas être handicapé par le fait de jouer plusieurs couleurs*.
              Ca n'atteignait sûrement pas les 1000 lignes, considérant que la plupart du taf était faite via l'IHM, donc via une lib.

              Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.

              J'ai aussi un script shell pour extraire les fichiers d'une archive jamendo dans une arborescence "artiste/album/*.???".

              Ainsi qu'un outil pour générer une classe C++ en ligne de commande en fonction d'un nom que je lui passe, qui hérite automatiquement d'une liste de classes que je lui passe en paramètres ( fonctionnalité prévue: l'ajout automatique des prototypes des fonctions virtuelles des classes mères, avec le mot-clé override fournit gratos, entres autres ).

              Je dois en citer d'autres, de petits utilitaires en dessous des 1000 lignes de code, ou tu as compris l'idée?
              En fait, le mot est placé: utilitaire.

              *: Ce qui me rappelle que le code source n'est pas "libre" ( surtout, pas diffusé ) mais j'avoue ne pas trop avoir imaginé qu'il puisse servir à quelqu'un… je dois encore l'avoir qui traîne sur un disque, je verrai p'tet pour le publier ce WE ^

              • [^] # Re: Evolution

                Posté par . Évalué à 2. Dernière modification le 28/02/14 à 21:03.

                Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.

                Et depuis Windows 7 elle est passée à WPF pour l'aspect présentation, et s'est enrichie de modes de fonctionnement additionnels. Comme quoi, même les outils "triviaux" changent.

                En fait, même notepad a changé.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Evolution

                  Posté par . Évalué à 0. Dernière modification le 28/02/14 à 21:06.

                  Passer à WPF c’est pas faire évoluer une application mais la réécrire.

                  Par contre GNU bc n’a pas eu de release depuis 2000, c’est qu’il doit être mort et inutilisable, n’ayant plus sa place que dans les musée de l’informatique, n’est-ce pas ?

                  • [^] # Re: Evolution

                    Posté par . Évalué à 3.

                    Passer à WPF c’est pas faire évoluer une application mais la réécrire.

                    Mais LOL. Elle doit être bien mal fichue ton application si changer la couche de présentation t'oblige à la réécrire de zéro.

                    Par contre GNU bc n’a pas eu de release depuis 2000, c’est qu’il doit être mort et inutilisable, n’ayant plus sa place que dans les musée de l’informatique, n’est-ce pas ?

                    C'est dommage, bc aurait pu rajouter des modes de calcul, par exemple.
                    Ce n'est pas parce que un logiciel n'évolue plus qu'il est feature-complete, hein. ;-)

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Evolution

                      Posté par . Évalué à -1. Dernière modification le 28/02/14 à 23:47.

                      Le truc, c’est que « feature-complete » est un choix que tout le monde ne fait pas et qui n’implique pas automagiquement que le logiciel est mort dans le sens « troué de bug et de failles de sécurité, incompilable sur les systèmes modernes… »

                      • [^] # Re: Evolution

                        Posté par . Évalué à 2.

                        C'est bien, je n'ai jamais dit ça. Mais pour le comprendre, faut sortir du cliché "logiciel qui n'évolue pas = logiciel parfait." ;-)

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: Evolution

                          Posté par . Évalué à 3. Dernière modification le 01/03/14 à 12:15.

                          https://linuxfr.org/users/carif/journaux/neovim-vim-s-rebirth-for-the-21st-century#comment-1522793

                          Tu as logiciel parfait => logiciel qui n’évolue pas

                          Personne n’a dit logiciel qui n’évolue pas => logiciel parfait.

                          Par contre ce qu’on dit c’est que c’est stupide de dire « meh, ce logiciel a pas évolué depuis 3 ans, c’est qu’il doit être mort et enterré ». Ça peut être aussi parce qu’il répond au besoin (et tout le monde n’a pas comme besoin « faire le café et promener le chien ») sans bug/faille connus, bref, qu’il est « parfait » (même si le terme est un peu prétentieux, je préfère le terme « fini » ;))

                          • [^] # Re: Evolution

                            Posté par . Évalué à 2.

                            Sauf que j'ai démontré que même les logiciels soi-disant "triviaux" (rm, ls, …) évoluaient toujours.

                            J'ose à peine encore demander un exemple d'un logiciel "fini superbement".

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Evolution

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

                              Je viens de vérifier. Même "/bin/true" a évolué entre 2003 et 2014…

                            • [^] # Re: Evolution

                              Posté par . Évalué à 0.

                              Tu en as un plus haut : GNU bc, dernière release 2000

                              • [^] # Re: Evolution

                                Posté par . Évalué à 5.

                                Ben non, vu qu'il y a des tests releases

                                Et la dernière date de 2006.

                                Et pourquoi il y a des tests releases ?
                                Parce que ça bug ! ;-)

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Evolution

      Posté par . Évalué à 2.

      La fonctionnalité ctrl+d de sublime texte serait aussi un plus agréable.
      Autre chose : Pourquoi le mode mouse=a ne permet pas la copie sur sélection de gnome dans gnome-terminal ?
      Si c'était possible, j'aimerai bien ça également.

      Après, je pense qu'il y aurait un bon travail à faire pour rendre le truc plus accessible en créant une meilleur doc en ligne mais c'est pas lié au logiciel directement.

      Enfin, s'il y avait un vrai logiciel graphique parfaitement adapté pour vim, je courrais l'acheter tout de suite (même gratuit).

      • [^] # Re: Evolution

        Posté par . Évalué à 8. Dernière modification le 25/02/14 à 21:14.

        Enfin, s'il y avait un vrai logiciel graphique parfaitement adapté pour vim, je courrais l'acheter tout de suite (même gratuit).

        As-tu essayé le mode vi disponible dans tous les logiciels KDE (via KatePart) ? Ce n'est pas un remplacement complet pour vim mais si tu es habitué aux commandes, ça te permet d'utiliser facilement ces logiciels (que ce soit pour développer avec kate/kdevelop, écrire un document latex avec kile ou tes mails avec kmail, etc.). Voir http://kate-editor.org/kate-vi-mode/

        • [^] # Re: Evolution

          Posté par (page perso) . Évalué à 2. Dernière modification le 26/02/14 à 11:24.

          Oui mais sans tes plugins, ta conf et pleins de plein de choses. C'est juste un mode frustrant.

          C'est dommage que vim n'est pas une interface graphique sous qt pour ceux qui veulent un environnement à la souris complet sous KDE/QT.
          En même temps, moi ça me gène pas, il suffit de lancer vim dans konsole et c'est intégré ^

          • [^] # Re: Evolution

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

            Je l'ai fait, ca s'appelait KVim et ça ne marche pas. Justement à cause de la structure monolithique de Vim. Neovim entend casser cette structure monolithique et permettra si il remplit ses objectifs de faire un KVim fonctionnel et facile à maintenir.

            • [^] # Re: Evolution

              Posté par . Évalué à 2. Dernière modification le 26/02/14 à 14:24.

              Et comment fait GVim alors ?

              • [^] # Re: Evolution

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

                Il fait des bidouilles qui marchent pas trop mal. Sauf que ce type de bidouille a ses limites. Pour un portage vers KDE en mode composant KPart, on a dépassé ces limites.

          • [^] # Re: Evolution

            Posté par . Évalué à 4.

            Oui mais sans tes plugins, ta conf et pleins de plein de choses. C'est juste un mode frustrant.
            il suffit de lancer vim dans konsole et c'est intégré ^

            Si tu as besoin de plugins vim, des fonctions avancées et de la conf de vim… ben tu utilises vim, point final. Mais si tu as besoin des plugins kdevelop, des fonctions avancées kdevelop et de la conf de kdevelop, mais que par ailleurs tu apprécies le style d'interaction homme-machine à la vi, alors tu coches juste la case dans la conf de Kate et c'est réglé. Il y a des raisons légitimes pour préférer un style d'interaction ; ne serait-ce que GTK et Qt n'ont pas la même interaction dans les zones de texte (par exemple si on fait Ctrl-Suppr. sur un mot entre deux autres, dans GTK ça laisse le curseur entre deux espaces, alors que dans Qt ça laisse le curseur juste avant le mot suivant. Ou bien si on fait Ctrl-→ pour se déplacer d'un mot à la fin d'une phrase, Qt place le curseur avant le point, GTK après le point).

      • [^] # Re: Evolution

        Posté par . Évalué à 3.

        Sous OSX (je sais…), MacVim est vraiment excellent.
        https://code.google.com/p/macvim/

        • [^] # Re: Evolution

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

          C'est à mes yeux la meilleure interface pour VIM, et de (très) loin, surtout quand on la compare à VIM dans un terminal ou à GVIM/Linux ou GVIM/Windows.

      • [^] # Re: Evolution

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

        Pourquoi le mode mouse=a ne permet pas la copie sur sélection de gnome dans gnome-terminal ?

        Parce que c'est trop compliqué pour madame Michu.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Evolution

        Posté par . Évalué à 2. Dernière modification le 26/02/14 à 08:54.

        gvim est peut-être ce que tu cherches : vim avec une fenêtre, un menu, les raccourcis dans le menu, tout ça…

        Pour Windows, il existe une version portable mise à disposition par le projet Framakey :
        http://framakey.org/Portables/VimPortable

        • [^] # Re: Evolution

          Posté par . Évalué à 2.

          J'ai renoncé à utiliser gViM sous Windows à cause d'une gestion extrêmement bizarre de la sélection à la souris (et du copier-coller), et du fait qu'involontairement je pouvais effacer du texte sélectionné là où sous Linux/UNIX ça ne m'arrivait jamais. Du coup lorsque je dois bosser sous Windows, j'utilise Notepad++.

      • [^] # Re: Evolution

        Posté par . Évalué à 1.

        Pourquoi le mode mouse=a ne permet pas la copie sur sélection de gnome dans gnome-terminal ?

        Il faut appuyer sur shift lors de la sélection (ou pendant le clic du milieu pour coller), sinon la sélection est interprétée comme le "visual mode" de vim.
        Voir http://stackoverflow.com/questions/4608161/copy-text-out-of-vim-with-set-mouse-a-enabled/4608387#4608387
        D'ailleurs le même "problème" se pose avec notamment midnight commander (mc) qui utilise également la souris, et ce n'est pas non plus spécifique à gnome-termnial.

      • [^] # Re: Evolution

        Posté par . Évalué à 1.

        Enfin, s'il y avait un vrai logiciel graphique parfaitement adapté pour vim

        Gvim ne te conviens pas ? il est pourtant pas mal.

        kentoc'h mervel eget bezan saotred

    • [^] # Re: Evolution

      Posté par . Évalué à 1.

      Je suppose qu'un système permettant d'éditer un fichier à plusieurs serait utilisable. Problème, je doute que ce fork finisse par en être capable, il faudrait faire plus que découpler des modules et refactorer du code pour ça.

      Pour ma part, probablement à cause du fait que je n'utilise vim que de façon basique, je trouve que la config est trop complexe à gérer ( j'avais regardé pour changer des bindings… les lignes de config m'ont fait penser "omg, usine à gaz spotted!" ). Mais la encore, je doute que ce fork fasse évoluer ça ( puisqu'il reste, naturellement, compatible avec l'original ).

      J'ajouterai enfin l'édition verticale, plutôt qu'horizontale. C'est peut-être possible, je n'ai jamais cherché. Après avoir tapé le "case :" dupliqué 20 fois d'un switch, que le curseur évolue à la verticale plutôt qu'à l'horizontale s/est/serait/ utile. Enfin, ici aussi, je m'en fiche, j'ai commencé à prendre l'habitude d'utiliser des tableaux associatifs dans mon code, au lieu de switch à rallonge. En plus ça me permets de faire du switch sur string en C++ ( avec des lambda ou pointeurs de fonction en valeur, c'est assez sympa et me blesse moins à maintenir que les 20k lignes d'un switch classique. Mais j'imagine que niveau perf c'est un peu moins terrible… ).

      Autrement dit, le fait de considérer vim comme fini dépend des gens :)

      • [^] # Re: Evolution

        Posté par . Évalué à 3.

        J'ajouterai enfin l'édition verticale, plutôt qu'horizontale. C'est peut-être possible, je n'ai jamais cherché. Après avoir tapé le "case :" dupliqué 20 fois d'un switch, que le curseur évolue à la verticale plutôt qu'à l'horizontale s/est/serait/ utile. Enfin, ici aussi, je m'en fiche, j'ai commencé à prendre l'habitude d'utiliser des tableaux associatifs dans mon code, au lieu de switch à rallonge. En plus ça me permets de faire du switch sur string en C++ ( avec des lambda ou pointeurs de fonction en valeur, c'est assez sympa et me blesse moins à maintenir que les 20k lignes d'un switch classique. Mais j'imagine que niveau perf c'est un peu moins terrible… ).

        Tu as regardé du coté des sélections carrées ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Evolution

          Posté par . Évalué à 1.

          Pas vraiment, mais ce n'est pas la même chose de sélectionner ( qui me sert surtout à copier/couper, je ne vois pas vraiment d'autres usages… ) ou de faire de l'édition en colonne. Ou alors j'ai mal compris ce que tu veux dire ( ce qui ne me surprendrais pas de ma part ).
          Maintenant que j'y pense, on pourrait également mentionner les curseurs multiples, qui sont aussi un outil très sympa quand ça ne bug pas ( c'est implémenté par scintilla, mais le fait de faire un retour à la ligne fait perdre le multi-curseur, et certaines autres actions ne fonctionnent pas ou sont bugguées. Enfin, c'était le cas quand j'utilisais encore autre chose que vim. ).
          Je doute que vim supporte ça. Mais je suis aussi persuadé que ce fork ne le supportera pas de sitôt, en admettant que la sauce prenne.

          • [^] # Re: Evolution

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

            Vraiment, tu devrais regarder de SublimeText. Il a un très gros inconvénient: il est closed source. En dehors de ça, il fait tout ce que tu décris et plus: curseur multiples, édition verticale (si j'ai bien compris), mapping Vim, extensibilité en Python, portable sur le trio Lin/Win/OsX

            • [^] # Re: Evolution

              Posté par . Évalué à 1. Dernière modification le 26/02/14 à 23:52.

              J'ai un collègue qui utilise cet outil, ça à effectivement l'air intéressant ( ceci dit, je ne savais pas qu'il tourne sous nux, le collègue en question restant sous win ).

              Maintenant, je dois t'avouer que ma tendance personnelle va de plus en plus à l'écriture de fichiers d'une très petite taille ( C++, donc 1 fichier par classe, et quand ça dépasse les 200 lignes, je divise pour envoyer le code dans le cpp. ), des classes ultra-spécialisées et sans me gêner pour utiliser des templates.
              Du coup, je ne suis pas sûr d'avoir encore besoin d'un éditeur de code très évolué: une fois que j'ai la coloration syntaxique, une auto-complétion potable et un système modal ( sur ce point, vim à changé ma vie, c'est une évidence ) je suis heureux, et donc mon usage basic de vim me conviens plutôt pas mal.
              Le tout combiné avec, en fait, un simple terminal pour naviguer dans les fichiers, est plus efficace que tout ce que j'ai pu voir avec des IDE classiques.
              Dommage d'ailleurs qu'il n'y ait pas un éditeur de code simple ayant ces 3 fonctionnalités avec une toute petite base de code, nul doute que je l'adopterai :)

              Le but de mon message était surtout d'argumenter sur le fait "oui, vim peut encore évoluer". Ces fonctionnalités, je m'en servirais de temps en temps, genre, 1 fois par mois. Rien d'important donc.

              Et puis, sans être un maniaque de l'open source ( j'utilise opera après tout ) je suis plutôt réticent à l'idée d'utiliser du code fermé.
              LA fonctionnalité qui pourrait me faire utiliser un nouveau logiciel fermé, ce serait d'être capable de générer des diagrammes à partir du code, et vice versa. Mais ce n'est pas le job d'un éditeur de code, ça.

          • [^] # Re: Evolution

            Posté par . Évalué à 2.

            Pas vraiment, mais ce n'est pas la même chose de sélectionner ( qui me sert surtout à copier/couper, je ne vois pas vraiment d'autres usages… ) ou de faire de l'édition en colonne. Ou alors j'ai mal compris ce que tu veux dire ( ce qui ne me surprendrais pas de ma part ).

            Oui je parle de faire une sélection carrée pour ensuite faire une édition par colonne. Je vois pas vraiment ce qu'il peut y avoir de plus pratique. En fait oui j'ai déjà vu des gens taper une fois un mot, puis le dupliquer n fois sur la même ligne et enfin les mettre tous à la ligne, mais je ne sais pas comment ils ont fait (sous vim). D'ailleurs pour ton cas il doit être possible de passer directement en je les mets tous à la ligne.

            Je présume que ça utilise des macros avec une bonne macro, on doit pouvoir faire des trucs de brutes, mais faut passer du temps pour bien maitriser je pense.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Evolution

              Posté par . Évalué à 2.

              Sur vim tu vas sur la ligne qui t'intéresses et tu fait yyp, ça a pour effet de dupliquer la ligne. Donc si tu veux dupliquer une ligne 5 ou 10 fois tu tapes 5 ou 10 fois p, mais si tu veux dupliquer 200 fois cette ligne tu fais naturellement yy200p et tu te retrouve avec 201 fois la même ligne (oui la première est toujours là :-D).
              Sinon pour les sélections carrées il faut entrer en mode visual bloc à l'aide de ctrl+v.

              avec une bonne macro, on doit pouvoir faire des trucs de brutes

              effectivement sous vim c'est les "map" ça s'utilise en faisant : map [touche_a_mapper] [combinaison_de_touches]
              Un exemple qui ajoute un # en début de ligne à l'aide de la touche F2 : map ^i#<DOWN><ESC>
              un exmple qui supprime le premier caractère d'une ligne à l'aide de la touche F3 : map ^x<DOWN>

              On peut évidemment les combiner avec les buffers, ainsi si on a :

              int fonction(int ,int)
              {
              
                return 0;
              }

              dans le buffer z le mappage : map "z200p vous dupliquera 200 fois ce squelette basique de fonction à chaque pression sur F3 \o/
              (j'adore les "map" on peut effectivement faire des trucs de fous).

              Il est aussi possible des les mettre dans le vimrc pour en bénéficier tout le temps, il est bon de noter qu'il vaut mieux éviter de "mapper" des touches ayant déjà une fonction comme a ou i par exemple, ça fonctionne mais au final on risque se retrouver perturbé (les utilisateurs de vim comprendrons pourquoi :-D).

              Un dernier truc si quelqu'un peut m'expliquer comment mapper des touches en fonction du type de fichier que l'on édite, par exemple si j'édite un .tex la touche F2 m'insérera

              \begin{figure}[!ht]
                  \centering
                  \includegraphics[]{}
                  \caption{}
                  \label{}
              \end{figure}

              Et si j'édite un fichier c cette même touche F2 m'insérera

              int main(int argc, char** argv)
              {
              
              return EXIT_SUCCESS;
              }

              je trouverais ça génial.

              kentoc'h mervel eget bezan saotred

              • [^] # Re: Evolution

                Posté par . Évalué à 2.

                mapper des touches en fonction du type de fichier que l'on édite

                Je dirais de placer les affectations dans le dossier ftplugin:
                .vim/ftplugin/tex.vim et .vim/ftplugin/c.vim

                Ensuite en utilisant les les paramètres <buffer> et <LocalLeader> de la commande map. (voir :h map-arguments)

                • [^] # Re: Evolution

                  Posté par . Évalué à 0.

                  j'essayerais et ferais un retour

                  kentoc'h mervel eget bezan saotred

              • [^] # Re: Evolution

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

                Et c'est dans ces moments-là qu'on voit les limites de VIM.
                Dans mon IDE favori, quand je change un raccourci clavier, il m'indique immédiatement la présence de conflits, dès que j'entre le nouveau raccourci clavier.

                Au final, j'ai beau avoir passé de longues heures à configurer un VIM pour faire du Python, il n'arrive toujours pas à la cheville de mon IDE brut de fonderie. Oui, on peut peut-être tout faire avec VIM, mais à quel prix…

                • [^] # Re: Evolution

                  Posté par . Évalué à 2.

                  La configuration de vim est clairement l'un des plus gros points noirs de cet outil.

              • [^] # Re: Evolution

                Posté par . Évalué à 2.

                Je pensais aux macro non mappées (comme décris là).

                si quelqu'un peut m'expliquer comment mapper des touches en fonction du type de fichier que l'on édite, par exemple si j'édite un .tex la touche F2 m'insérera

                au FileType tex map ^i#<DOWN><ESC>
                " ou
                au BufNewFile,BufRead *.tex map ^i#<DOWN><ESC>

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Evolution

              Posté par . Évalué à 1.

              Bof, si c'est juste créer des lignes avec le même contenu, c'est facile:

              :5oblablabla[esc]
              écrira:
              blablabla
              blablabla
              blablabla
              blablabla
              blablabla

              Sauf que ça crée des lignes, donc pas toujours idéal. Par exemple, imagines un code qui utilise "use namespace std;", et la convention de codage du projet dit que les "use namespace" sont interdits. Comment ajouter facilement le "std::" à chaque endroit du code ou il est nécessaire?

              Bon, c'est assez limite comme cas, j'avoue, mais pour les autres auxquels je pense, on peut utiliser une combo entre la méthode que j'ai mise pour créer N lignes identiques et/ou le remplacement via des regex :)

              • [^] # Re: Evolution

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

                C'est un besoin extrêmement courant.

                Sous Vim, j'aurai tendance à faire une macro vite fait: je me mets au début du premier blabla, je tape qq, je fais ma modif et ma place sur le 2e blabla, et je tape q, puis @q pour répéter sur les lignes suivantes.

                Sous SublimeText, je pose le curseur sur le premier bla, je duplique le curseur sur les 6 lignes avec Ctrl+Alt+Down. Ensuite, j'édite mes 6 lignes simultanément, en profitant d'un feedback visuel immédiat.

                • [^] # Re: Evolution

                  Posté par . Évalué à 3.

                  Tu peux le faire je pense aussi facilement avec vim.

                  Tu te mets au début de premier blabla, tu passes en mode VISUEL BLOC (ctrl + v), tu descends jusqu'au niveau du 6ème blabla, tu passes en mode insertion (avec shift + i), tu édites directement ta ligne, puis échappe, et toutes tes lignes sont édités.

                  La différence, c'est que le rendu ne s'effectue qu'à la fin sur les autres lignes.

                  • [^] # Re: Evolution

                    Posté par . Évalué à 1.

                    Ça, c'est génial! Merci beaucoup!!!

                    Oui, je sais, commentaire inutile, mais je tenais à te remercier.

      • [^] # Re: Evolution

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

        Je suppose qu'un système permettant d'éditer un fichier à plusieurs serait utilisable.

        https://github.com/FredKSchott/CoVim

        (je n'ai pas testé)

  • # Profitons-en

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

    Profitons d'un nourjal sur Vim pour parler de ce superbe site qu'est http://vimcasts.org/ !

    Si vous voulez profiter au mieux de Vim, apprendre des nouveaux trucs et découvrir des plugins, c'est le site rêvé !

    It's a fez. I wear a fez now. Fezes are cool !

  • # Plugin par défaut

    Posté par . Évalué à 5.

    J'utilise personnellement vim avec grand plaisir, mais j'ai failli abandonner récemment son utilisation, car des fonctionnalités très pratique sont absentes de vim. Je pense par exemple à un gestionnaire de fichier, une gestion des ctags, des snippets, une insertion automatique des parenthèses () [] {} <>, l'affichage du prototype des fonctions, … Mais heureusement, j'ai découvert les plugins. Une fois bien configuré, vim est le meilleur logiciel que je connaisse, mais cela prend énormément de temps. Je ne comprends pas pourquoi il n'y a pas un ensemble de plugins (dont vundle ou pathogen) d'installé par défaut avec vim. Cela permettrait d'avoir un véritable éditeur de texte moderne, pouvant servir d'ide, et très hautement personnalisable. Les plugins installé par défauts devant évidement pouvoir être désinstallé de manière classique. Cela permettrait d'avoir un vim plus intelligent à l'installation, mais possédant toutes les qualités de vim, et compatible avec toutes les configurations exotiques des anciens utilisateurs (il leur suffirait de restaurer le .vim et le .vimrc).

    De la même façon, je n'ai pas commencé par LFS (linux from scratch), mais par ubuntu, et je suis désormais sous archlinux.

    bépo powered

    • [^] # Re: Plugin par défaut

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

      Tant que tu y es, propose d'installer Cream par défaut :-D

    • [^] # Re: Plugin par défaut

      Posté par . Évalué à 2.

      Je suppose qu'il est possible de créer un paquet dépendant de vim et des plug-in que tu souhaites, et les activant automatiquement.
      C'est d'ailleurs exactement ce qu'eclipse fait, car sans plug-in cette usine à gaz ne fait juste rien.

      Il faut juste trouvé un motivé qui ne craigne pas de récolter l'opprobe générale ( et ça part vite chez les barbus ;) ) en déterminant de façon totalement subjective et personnelle quels plug-ins liés à quelle configuration peuvent rendre vim aussi puissants qu'eclipse.

      Sincèrement, si tu oses le faire je te soutien sans condition.

      • [^] # Re: Plugin par défaut

        Posté par . Évalué à 2.

        Il y a déjà des « distribution vim » comme sp13 et janus, mais elles ne sont pas officielle, et c'est la tout le problème. Si on fait le parallèle avec le c++, il existe des dizaines de librairies pour faire à peu près tout, mais un comité de normalisation se réunit régulièrement pour avoir une librairie commune pour les besoins de base. Libre ensuite à l'utilisateur de la garder (je pense aux Qstring dans Qt par exemple). Je trouve que c'est vraiment quelque-chose qui manque dans la communauté vim.

        De plus, l'avantage d'un comité de normalisation est qu'il permettrait de tester des configurations un peu étrange. Pour mon cas, j'utilise un clavier en bépo, et la distribution sp13 (que je trouve très bien par ailleurs) nécessite quelques modifications dû à des effets de bords lors de certain remap. Une solution standard n'aurait pas ce type de problème.

        En imaginant que j'ai les compétences pour le faire (je ne connais pas assez vim – j'ai par exemple récemment découvert les autocommandes, et je me doute qu'il y a encore des trucs dont je n'ai pas la moindre idée de leur existence), je n'aurais pas l'influence nécessaire pour que vim soit distribué avec par défaut une liste de plugin que j'aurais choisis dans toutes les distributions linux, windows et mac. Comme je le disais, le problème n'est pas le manque de fonctionnalités de vim, mais le fait que ces fonctionnalités ne sont pas présente à l'installation.

        bépo powered

        • [^] # Re: Plugin par défaut

          Posté par . Évalué à 0. Dernière modification le 02/03/14 à 21:53.

          Comme je le disais, le problème n'est pas le manque de fonctionnalités de vim, mais le fait que ces fonctionnalités ne sont pas présente à l'installation.

          Pas moi qui l'ai dit, que vim manque de fonctionnalités :)

          Enfin, si, mais je suis clairement persuadé qu'on peut le transformer en IDE complet… ce qui ne gommera pas ses défauts. Et pour les distrib de vim que tu cites, je ne les connaissais pas ( je n'y connais pas grand chose , il faut dire ), et je testerai. Sauf que… je doute qu'il y ait une intro simple à comprendre, ou qu'ils aient gommé les défauts de vim, dont la config complexe fait clairement partie. Selon moi, du moins.

          Et quand on voit le temps que mets le comité C++ à se décider pour une nouvelle norme ( 8 ans pour C++11, si on considère la bugfix 03 comme une norme a part entière… que personne de mémoire n'a entièrement implémentée d'ailleurs ) je doute que ce soit une solution.
          Qui plus est, comment trouver un système pour que ce que l'on utilise pas du standard ne coûte rien, comme en C++? ( ce qui n'est pas inclut ni demandé explicitement n'est pas utilisé en C++, donc pas payé. Exceptions, RTTI, ce genre de choses. On peut aussi les désactiver explicitement, mais en théorie ce n'est pas utile. J'ai bien dit théorie, hein? )

          • [^] # Re: Plugin par défaut

            Posté par . Évalué à 3.

            Et quand on voit le temps que mets le comité C++ à se décider pour une nouvelle norme ( 8 ans pour C++11, si on considère la bugfix 03 comme une norme a part entière… que personne de mémoire n'a entièrement implémentée d'ailleurs ) je doute que ce soit une solution.

            Tu parle de ceux qui prévoient de sortir en C++14 et un C++17 ? ;)
            http://en.wikipedia.org/wiki/C%2B%2B#Standardization

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Plugin par défaut

              Posté par . Évalué à 1.

              Oui. En même temps, ils avaient prévu de sortir C++11 avant 2010, d'où le nom du draft: C++0x.
              Ceux qui inventent des excuses diront qu'on parle d'hexadécimal, mais j'ose espérer que personne n'est dupe.

              Entre prévoir et faire, il y a une grande différence.

              Après, je suis d'accord: on parle de standard ISO, donc il faut faire les choses bien, ce qui peut prendre du temps. Mais bon, 13 ans ( standardisation en 98 selon wikipedia, bugfix en 03 ) pour une nouvelle version, en info, c'est long.
              Mais bon, ça n'empêche pas ce langage d'être mon favori, vu qu'avec les fonctionnalités de base on peut faire déjà énormément, et au moins on a peu de choses qui deviennent obsolètes ( mais ça existe malgré tout, comme auto_ptr ).

              • [^] # Re: Plugin par défaut

                Posté par . Évalué à 2.

                C'était un exemple, le JCP (ceux qui font Java) accélèrent et java 8 arriveras cette année (et oui il arrivera cette année vu qu'Oracle annonce clairement qu'ils le sortent même s'il y a des bugs), python aussi a le même processus et est assez court. Le W3C a passé HTML5 en rolling release, etc…

                Les commités commencent à comprendre que s'ils veulent garder leur boulot, il faut qu'ils se bougent et accélèrent grandement leur processus quitte à avoir des normes avec moins de nouveautés (le problème de C++0x a était entre autre les concepts qui étaient de trop malheureusement).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Plugin par défaut

                  Posté par . Évalué à 1.

                  Moui, enfin, C++ est quand même le plus lent à évoluer. Pour faire court, selon wikipedia, en 18 ans, Java à fait l'objet de 8 versions ( qui ne soient pas des bugfix ), python en à une tous les 2 ans, quand C++ en est à sa 2nde version standard, 3 si on compte la bugfix de 03.
                  Avec le w3c, il ne s'agit pas de standard, mais de recommandations, si ma mémoire est bonne. Recommandations qui ne sont respectées complètement par presque aucun site de ma connaissance. En pourcentage, ça doit donner de l'ordre du 5%, peut-être même moins! ( je pense être très optimiste avec mon 5%… )
                  Et il ne s'agit pas d'un langage de programmation, mais de description. Quand vim se configure, lui, avec un langage de programmation.

                  D'un autre côté, je peux comprendre, et accepter, que C++ soit plus long à standardiser.
                  Je ne voudrais pas que la quantité passe avant la qualité, franchement, donc qu'il ne fasse pas comme Oracle et son Java ou python ou les révisions mineures semblent empêcher d'interpréter des codes faits avec la rev mineure précédente ( lu je ne sais plus où sur ce dlfp ). Ca me va très bien comme ça.
                  Mais des MaJ plus petites, tout aussi propres et plus fréquentes, ça me ferait bien plaisir tout de même. Il n'empêche, le fait qu'ils en annoncent 1 pour cette année, n'implique pas que les délais seront tenus. Les procédures pour un standard ISO sont certainement nettement plus complexes que d'attendre l'approbation d'Oracle ou attendre qu'une équipe de dev open source accepte une contribution, cas de python. On parle d'un organisme de standardisation international reconnu par de nombreux pays, après tout.
                  Maintenant, en C++11, on peut toujours compiler du code qui date de 98, je ne suis pas sûr que ce soit le cas de la majorité des autres langages.
                  A part le langage de config de vim, j'imagine :)

                  • [^] # Re: Plugin par défaut

                    Posté par . Évalué à 3.

                    La différence c'est que C++ c'est une norme, et pas seulement un standard. Donc il faut que tous les membres du comité de normalisation soient d'accord, et donc on se retrouve avec des gens de Microsoft par exemple qui ont certains usages courants et des extensions qu'ils voudraient voir normalisés; idem pour les autres participants. Python, Perl, Ruby, Java, etc., même s'ils demandent leur avis aux utilisateurs, restent principalement une implémentation « unique ». Oui je sais, il existe plusieurs implém de Ruby, Python, Java, etc. La différence (selon moi), c'est que globalement il y a une version qui continue d'évoluer en permanence, là où en C ou C++, on se retrouve avec 12000 compilateurs (Sun CC, Intel CC, Gnu CC, Clang+LLVM, etc.). Bien qu'il existe des trucs du genre « Iron{Python,Ruby} » ou même des implémentations alternatives de Java, c'est ultra minoritaire en pratique.

                    • [^] # Re: Plugin par défaut

                      Posté par . Évalué à 1.

                      Je pense que python a plus d'implémentation que C++ n'a de parseur… :)

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Plugin par défaut

                        Posté par . Évalué à 1.

                        Quels sont les ports de Python qui sont des implémentations qui continuent d'évoluer ? C'est une vraie question. J'ai en tête les distributions suivantes:

                        • Python / POSIX
                        • IronPython (.Net)
                        • Active Python
                        • Pypy?

                        J'ai entendu parler d'autres implémentations, mais qui semblent évoluer peu ou pas du tout :

                        • CPython
                        • Jython
                        • Cython
                        • D'autres que j'ai ratés, sans doute.

                        Je me plante complètement ?

                        De l'autre côté, niveau front-ends pour C++, je dénombre (sans trop me prendre la tête):

                        • GNU C++
                        • MS Visual C++
                        • Intel C++
                        • Sun/Oracle Studio
                        • Digital Mars C++
                        • IBM C++
                        • Clang++
                        • HP C++

                        (Note qu'à part g++, clang++, et peut-être icc, je ne crois pas que la plupart de ces compilos gèrent correctement C++11)

                  • [^] # Re: Plugin par défaut

                    Posté par . Évalué à 2.

                    Moui, enfin, C++ est quand même le plus lent à évoluer.

                    C'était pas vraiment la question. Je voulais juste montrer que ce n'est pas parce qu'il y a un ensemble de gens qui doivent se mettre d'accord que c'est super long. vim n'est pas un standard (contrairement à ed et vi) donc sa conf et ses plugins n'ont pas à l'être. L'intérêt c'est juste de mettre un peu d'ordre (sachant qu'il n'est pas envisageable de mettre d'accord l'ensemble des communautés et des gens qui utilisent vi/vim, il y en a trop et depuis trop longtemps).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Plugin par défaut

                      Posté par . Évalué à 1.

                      Point sur lequel on est d'accord.

                      Le souci étant, que mettre d'accord des gens, ça prend du temps. Et la, on parle d'utilisateurs de vim, des "barbus" qui ont lutté contre "l'ennemi" emacs sur de nombre de forums, etc etc.
                      Bref, la moindre tentative d'uniformisation de vim risque d'aboutir à la naissance d'un nouveau standard, en plus d'être longue à mettre en place.

                      • [^] # Re: Plugin par défaut

                        Posté par . Évalué à 1.

                        Vous pensez sincèrement que si Vundle, un .vimrc.bundle, et que la valeur par défaut de certain paramètres (mais avec une nouvelle option « set nonew », fournie par défaut, les barbus pourraient se sentir lésés ? L'idée étant que si on rajoute au début de son .vimrc historique le « set nonew », il n'y ait aucun changement.

                        bépo powered

Suivre le flux des commentaires

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