> Vim, et les applications KDE ont des «philosophies» radicalement opposées
Oui et non. KDE, c'est ce qu'on en fait. Il y a avant-tout une grosse pression sur la facilite d'utilisation, mais il y a aussi une grosse communaute de hackers sur KDE, ce qui fait que KDE convient aussi a un hacker de fond. Il n'y a qu'a voir les possiblites de konqueror ou de dcop pour s'en convaincre.
> Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?
De kvim, j'attend un editeur gvim avec les icones et les menus KDE. Ca, ca va on l'a fait mais ca n'a pas ete sans quelques bidouilles. Apres, l'etape importante, c'est l'integration d'un composant editeur compatible vi dans KDE. Tu serais surpris du nombre de personnes qui sont interessees par ce truc. Les demandes les plus fortes pour ce genre d'integration sont pour KDevelop et Quanta+: des logiciels de developpeurs a qui un vim ne fait pas peur. Avoir un bon Kate avec vi pour la partie editeur etait aussi un de mes reves. Malheureusement, la structure de vim ne le permet pas.
Pour en revenir a la question, pour faire un composant vi pour KDE, il parait naturel de se tourner vers le meilleur editeur vi qui soit, a savoir vim. Malheureusement, en raison d'une part de l'architecture de vim un peu trop orientee C, d'autre part de l'entetement de l'auteur a refuser tout patch, il n'est pas possible de faire de vim un composant editeur KDE proprement. Je dis ca bien que vous puissiez utiliser kvim aujourd'hui dans kdevelop mais a un prix en developpement que vous ne pouvez pas imaginer. Il y a par exemple une chance sur 5 que kvim se lance en dehors de la fenetre de kdevelop.
> Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités
J'ai pris les fonctionnalites qui etaient significatives par rapport a ce que je demandais. Les trois fonctionnalites citees sont des fonctionnalites que nous avons demandees a Bram en exposant notre point de vue pendant une longue discussion pour aboutir au final au rejet de notre proposition. A cause de cela, et presque contre notre gre, nous avons demarre un projet d'editeur compatible vim concurrent: yzis.
Je trouve ca ironique qu'apres nous avoir envoye bouler, il figure parmi les fonctionnalites les plus demandees precisement les fonctionnalites que Bram a refuse qu'on ajoute.
Pour finir sur Yzis, je citerai la phrase de Mickael (un des initiateurs du projet): "il faut deux ans pour que Bram integre un patch de notre part dans vim. En deux ans, on a le temps de redevelopper un editeur".
Yzis presente un certains nombre d'avantages indeniables sur vim, meme s'il est encore tres jeune:
- un langage de script reconnu et massivement diffuse: lua (v5.0)
- un support de la coloration syntaxique beaucoup plus puissant et plus simple a ecrire, base en particulier sur des fichiers xml et partage avec l'editeur kate/kwrite
- une abstraction frontend / moteur vi qui permet de reutiliser le moteur yzis dans plein de circonstances
- une utilisation massive de bibliotheques deja existantes de debuggees plutot que l'utilisation de truc faits maison.
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 9.
Oui et non. KDE, c'est ce qu'on en fait. Il y a avant-tout une grosse pression sur la facilite d'utilisation, mais il y a aussi une grosse communaute de hackers sur KDE, ce qui fait que KDE convient aussi a un hacker de fond. Il n'y a qu'a voir les possiblites de konqueror ou de dcop pour s'en convaincre.
> Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?
De kvim, j'attend un editeur gvim avec les icones et les menus KDE. Ca, ca va on l'a fait mais ca n'a pas ete sans quelques bidouilles. Apres, l'etape importante, c'est l'integration d'un composant editeur compatible vi dans KDE. Tu serais surpris du nombre de personnes qui sont interessees par ce truc. Les demandes les plus fortes pour ce genre d'integration sont pour KDevelop et Quanta+: des logiciels de developpeurs a qui un vim ne fait pas peur. Avoir un bon Kate avec vi pour la partie editeur etait aussi un de mes reves. Malheureusement, la structure de vim ne le permet pas.
Pour en revenir a la question, pour faire un composant vi pour KDE, il parait naturel de se tourner vers le meilleur editeur vi qui soit, a savoir vim. Malheureusement, en raison d'une part de l'architecture de vim un peu trop orientee C, d'autre part de l'entetement de l'auteur a refuser tout patch, il n'est pas possible de faire de vim un composant editeur KDE proprement. Je dis ca bien que vous puissiez utiliser kvim aujourd'hui dans kdevelop mais a un prix en developpement que vous ne pouvez pas imaginer. Il y a par exemple une chance sur 5 que kvim se lance en dehors de la fenetre de kdevelop.
> Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités
J'ai pris les fonctionnalites qui etaient significatives par rapport a ce que je demandais. Les trois fonctionnalites citees sont des fonctionnalites que nous avons demandees a Bram en exposant notre point de vue pendant une longue discussion pour aboutir au final au rejet de notre proposition. A cause de cela, et presque contre notre gre, nous avons demarre un projet d'editeur compatible vim concurrent: yzis.
Je trouve ca ironique qu'apres nous avoir envoye bouler, il figure parmi les fonctionnalites les plus demandees precisement les fonctionnalites que Bram a refuse qu'on ajoute.
Pour finir sur Yzis, je citerai la phrase de Mickael (un des initiateurs du projet): "il faut deux ans pour que Bram integre un patch de notre part dans vim. En deux ans, on a le temps de redevelopper un editeur".
Yzis presente un certains nombre d'avantages indeniables sur vim, meme s'il est encore tres jeune:
- un langage de script reconnu et massivement diffuse: lua (v5.0)
- un support de la coloration syntaxique beaucoup plus puissant et plus simple a ecrire, base en particulier sur des fichiers xml et partage avec l'editeur kate/kwrite
- une abstraction frontend / moteur vi qui permet de reutiliser le moteur yzis dans plein de circonstances
- une utilisation massive de bibliotheques deja existantes de debuggees plutot que l'utilisation de truc faits maison.