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 Philippe F (site web personnel) . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
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 !