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 Philippe F (site web personnel) . En réponse au journal Neovim : vim's rebirth for the 21st century. É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:
Les points négatifs:
pour citer des gros points faibles :
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...