Voilà, il tente de corriger les limites de VimL : ce n'étaient pas forcément un défaut et n'avait pas été accueilli comme tel ; mais avec l'évolution des contributions et les plugins qui deviennent de véritables applications ça commence à s'essouffler.
Encore une fois, Lua (et pas que) est déjà disponible avec Vim (Neovim ne l'a pas inventé) mais n'est pas tant utilisé que ça (même dans Neovim il y a pas mal de plugins utilisant VimL.) Outre ce constat, ces langages éprouvés et robustes, comme tu dis, se heurtent à un mur : ce n'est pas du natif mais une traduction en quelque chose qui sera interprété par Vim (comme l'est VimL.)
Par contre, je pense (et croise les doigts car n'ayant pas regardé l'évolution du code) que ce travail va bénéficier à tous : le mur sera repoussé pour les autres langages qui s'exécuteront plus vite aussi.
Comme tu n'as pas regardé la doc, tu n'as pas compris que la rétrocompatibilité est conservée. Les scripts pour Vim7 continueront à fonctionner avec Vim9. Par contre, si power-user décide de faire un truc pour Vim>9 ça ne bénéficiera pas aux anciennes versions (encore que les mécanismes pour faire le taf en double sont prévu si certaines personnes y tiennent ; auquel cas on aura un truc plus rapide avec Vim9 et suivant mais qui marchera quand même pour les anciens.)
On a déjà eu le cas avec chaque version majeure depuis Vim4 : des ajouts qui fonctionnent pour les nouvelles versions mais pas les anciennes, tout en gardant la compatibilité. La seule question est donc qui va l'utiliser. Et si ce n'est pas utiliser, bah y aura qu'à retirer de Vim10. Évolution et non fragmentation (FUD gratuit)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Ça Bram dans les repos
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Vim9 script feature-complete. Évalué à 1.
Voilà, il tente de corriger les limites de VimL : ce n'étaient pas forcément un défaut et n'avait pas été accueilli comme tel ; mais avec l'évolution des contributions et les plugins qui deviennent de véritables applications ça commence à s'essouffler.
Encore une fois, Lua (et pas que) est déjà disponible avec Vim (Neovim ne l'a pas inventé) mais n'est pas tant utilisé que ça (même dans Neovim il y a pas mal de plugins utilisant VimL.) Outre ce constat, ces langages éprouvés et robustes, comme tu dis, se heurtent à un mur : ce n'est pas du natif mais une traduction en quelque chose qui sera interprété par Vim (comme l'est VimL.)
Par contre, je pense (et croise les doigts car n'ayant pas regardé l'évolution du code) que ce travail va bénéficier à tous : le mur sera repoussé pour les autres langages qui s'exécuteront plus vite aussi.
Comme tu n'as pas regardé la doc, tu n'as pas compris que la rétrocompatibilité est conservée. Les scripts pour Vim7 continueront à fonctionner avec Vim9. Par contre, si power-user décide de faire un truc pour Vim>9 ça ne bénéficiera pas aux anciennes versions (encore que les mécanismes pour faire le taf en double sont prévu si certaines personnes y tiennent ; auquel cas on aura un truc plus rapide avec Vim9 et suivant mais qui marchera quand même pour les anciens.)
On a déjà eu le cas avec chaque version majeure depuis Vim4 : des ajouts qui fonctionnent pour les nouvelles versions mais pas les anciennes, tout en gardant la compatibilité. La seule question est donc qui va l'utiliser. Et si ce n'est pas utiliser, bah y aura qu'à retirer de Vim10. Évolution et non fragmentation (FUD gratuit)
"It is seldom that liberty of any kind is lost all at once." ― David Hume