Cependant elle n'est pas à négliger car elle contient toujours plus de fichiers de syntaxe, de traductions dans divers langages etc...
Il est à noter qu'il est désormais possible de s'enregistrer, afin de supporter financièrement ce magnifique outil qu'est Vim. En devenant sponsor, on dispose alors d'un droit de vote afin de choisir les fonctionnalités les plus désirées susceptibles d'être intégrées dans ses futures versions.
NdM: merci de ne pas partir en troll vi(m) vs emacs
Aller plus loin
- Vim le site officiel (4 clics)
- Le lien pour le téléchargement (2 clics)
# Traduction ?
Posté par Thomas Pedoussaut . Évalué à 0.
[^] # Re: Traduction ?
Posté par soulflyb (Mastodon) . Évalué à 6.
(tiens, en plus "language" est en rouge chez moi :) )
[^] # Re: Traduction ?
Posté par Boris . Évalué à 2.
[^] # Re: Traduction ?
Posté par zgnouf . Évalué à 4.
[^] # Re: Traduction ?
Posté par TazForEver . Évalué à -1.
« La langue est le système de communication propre à une communauté linguistique. »
pas mal, mais tu peux faire mieux
HIRD / HURD :o
# vi(m) vs emacs
Posté par Thomas J. (site web personnel) . Évalué à -9.
Je vais allumer un sierge et faire une prière pour que tu puisses être entendu !
[^] # Re: vi(m) vs emacs
Posté par theocrite (site web personnel) . Évalué à -3.
Non tu n'as as été entendu (cf le commentaire juste au dessous).
[^] # Re: vi(m) vs emacs
Posté par Thomas J. (site web personnel) . Évalué à -4.
# [TROLL]
Posté par dlfpbot . Évalué à -10.
Bientôt aussi bloted qu'emacs notre vim adoré...
Cependant elle n'est pas à négliger car elle contient toujours plus de fichiers de syntaxe, de traductions dans divers langage etc...
elvis ro><or
[^] # Re: [TROLL]
Posté par Infernal Quack (site web personnel) . Évalué à -1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: [TROLL]
Posté par nicodache . Évalué à -1.
# Rubrique
Posté par Aurélien Bompard (site web personnel) . Évalué à -3.
[^] # Re: Rubrique
Posté par Gabriel . Évalué à -5.
[^] # Re: Rubrique
Posté par Xavier Teyssier (site web personnel) . Évalué à -2.
[^] # Re: Rubrique
Posté par cosmocat . Évalué à 9.
http://woof.lu/office/vi.asp(...)
[^] # Re: Rubrique
Posté par EppO (site web personnel) . Évalué à 1.
Franchement, bravo !
# Yzis
Posté par Philippe F (site web personnel) . Évalué à 9.
Pour ce qui est de l'integration des nouvelles fonctionnalites, j'espere que Bram se comportera mieux que par le passe mais je n'y crois pas. Il ne lui a fallu << que >> deux ans pour integrer les patch de kvim dans vim. Des que tu lui demandes de changer une ligne de code, il faut compter entre 1 et 12 mois de discussions et negociations. Alors pour une nouvelle fonctionnalite, j'ose pas imaginer.
[^] # Re: Yzis
Posté par MsK` . Évalué à 1.
[^] # Re: Yzis
Posté par dguihal . Évalué à 3.
http://www.yzis.org/~orzel/screenshots/(...)
[^] # Re: Yzis
Posté par Frederick Ros . Évalué à 2.
[^] # Re: Yzis
Posté par Frederick Ros . Évalué à -1.
[^] # Re: Yzis
Posté par Olivier Dupuis . Évalué à 4.
Par contre sauter sur l'éditeur que tu es en train de développer, c'est super tendance ?
A part ça, l'accès à ftp://download.yzis.org/yzis/releases(...) depuis la page de téléchargement d'Yzis retourne 550 : failed to change directory.
[^] # Re: Yzis
Posté par Mickael Marchand . Évalué à 1.
j'ai repare le ftp
de toute facon mieux vaut utiliser les snapshots, ca a bien change depuis M1 ;)
Mik
[^] # Re: Yzis
Posté par Philippe F (site web personnel) . Évalué à 2.
Historiquement dans le logiciel libre, on a vu des projets qui se sont scindes en un projet stable qui n'evolue plus et un projet dynamique, moins stable, qui evolue plus vite (gcc vs egcs par exemple, ou emacs vs Xemacs, ). De ce que j'en ai vu, le projet qui evolue prend a terme au moins 50% des utilisateurs, voire dans certains cas enterre l'autre projet.
# Vim 7
Posté par gnujsa . Évalué à 10.
http://www.vim.org/sponsor/vote_results.php(...)
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . Évalué à 10.
104 points: support embedding of Vim in another GUI program
Apres plus de trois ans de bataille avec le code de vim, et un certain nombre de discussion avec Bram, il est apparu que le GUI graphique ne faisait pas partie des priorites de Bram, ni meme de son champ de comprehension. Apparamment, c'est pourtant la priorite des utilisateurs. Pire, il est apparu que Bram ne comprenait pas vraiment les besoins d'un bon GUI graphique et surtout n'envisageait pas de changer une ligne de code de vim pour supporter quoi que ce soit dans ce sens. A cause de cela, kvim est bourre de hacks qui permettent vaguement de lancer kvim sans prendre 100% de cpu si il est de bonne humeur. Vous pleureriez si vous saviez comment on arrive a faire un composant vim pour KDE a partir de ca.
La derniere fois qu'on lui a demande de separer vim en un moteur vim et un gui vim pour faciliter l'integration graphique, il a dit qu'il ne toucherait pas a ces parties la et que vim resterait tel qu'il est, un editeur oriente terminal. Les changements seraient de toute maniere trop profond pour pouvoir etre realises. Je me demande si il a juste change d'avis et ne realise pas l'ampleur de la tache maintenant, ou si il s'est juste foutu de notre gueule a l'epoque.
A mon avis, vous pouvez toujours rever mais vous n'etes pas pret d'avoir un bon gui pour vim. Par bon gui, j'entends un truc qui ne soit pas equivalent a xterm + vim mais plutot un gui incrustable dans kdevelop, quanta ou kmail.
74 points : add IDE features (debugger integration, shell window)
Dites-moi, il a bien change Bram. Pareil, quand on lui a dit que separer vim en un moteur et un frontend permettrait d'integrer vim dans un IDE style KDevelop, il a dit que c'etait ce qu'il voulait (bien qu'il n'accepte aucun patch allant dans cette direction) et que vim ne devait pas devenir un IDE en soi.
62 points: support multiple top-level windows for one running Vim
La aussi, ca me fait marrer. Parmi toutes les directions qu'il ne voulait pas prendre, celle-ci semble quand meme la plus facile a ajouter au code.
[^] # Re: Vim 7
Posté par M . Évalué à 5.
Et encore faut mieux eviter de lancer vim sur un vrai vt100 via le port serie, sinon imposible d'en sortir (vim recoit n'importe quoi comme caractere), et si on est en single mode on est bon pour le reboot.
[^] # Re: Vim 7
Posté par Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Vim 7
Posté par dguihal . Évalué à 4.
[^] # Re: Vim 7
Posté par Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Vim 7
Posté par dguihal . Évalué à 1.
[^] # Re: Vim 7
Posté par phenix (site web personnel) . Évalué à 3.
Quand je vois a quois les vt100 resemblent, ca fait rever, je me dit que sa dois etre sympas de pouvoir utiliser son shell linux la dessus.
Et en plus, ca permeterais qu'une machine puisse etre utilisée par plusieurs personnes en même temps
Sinon, comme terminal, y'a aussi le minitel. Des que j'en trouve un, il faut vraiment que je teste
http://n.ethz.ch/student/antoinet/minitel.html(...)
Par contre, vim par minitel je ne sait pas ce que ca donne :)
Sinon pour ce qui est de vim normal, je le trouve un peu dure a maitriser, j'ai deja lu quelques howto, mais je comprend pas la philosophie du logiciel.
J'utilise personellement gvim -y. Ca m'apporte ce que j'aime bien dans vim, mais egalement ce que j'aime bien dans emacs
[^] # Re: Vim 7
Posté par __caffeine__ . Évalué à 2.
http://vt100.net(...)
c'est vrai que ça me plairaît bien cette petite bête...
[^] # Re: Vim 7
Posté par gnujsa . Évalué à 10.
A l'opposé, les applications KDE se manipulent à la souris, elles nécessitent (dans l'idéale) aucun apprentissage: elles sont hyper intuitives. Il existe en plus, déjà, de très bon éditeurs texte sous KDE (kate/kwrite). Je préférerais, que dans le futur, Vim continue sur sa voie, et se vimifie (comme le bon vin ) et que les applications KDE continue elle aussi dans le domaine ou elles excellent: intégration dans KDE, intuitivité, etc..
Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?
Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités: tu site la demande n°4 « support embedding of Vim in another GUI program» (105pts), en oubliant la demande n°1 « add intelligent, context-sensitive completion (intellisense)» (209pts) qui, elle, va dans le sens (à mon avis) d' «un vim encore plus vim»
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . É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.
[^] # Re: Vim 7
Posté par gpe . Évalué à 2.
Est-ce que Yzis est intégrable dans autre chose que KDE?
[^] # Re: Vim 7
Posté par Mickael Marchand . Évalué à 2.
on a peut-etre quelqu'un qui va s'en occuper mais c'est pas encore fait, mais on est encore dans les debuts d'yzis. L'avenir nous le dira.
En tout cas, techniquement, yzis a ete fait pour.
Mik
[^] # Re: Vim 7
Posté par rhizome . Évalué à 0.
[^] # Re: Vim 7
Posté par jmfayard . Évalué à 3.
[^] # Re: Vim 7
Posté par troll hunter . Évalué à -1.
Vim est leger et rapide. KDE est lourd et lent.
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . Évalué à -2.
# Intégrer Vim dans Gnome..
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Visiblement, il n'en est pas de même dans Gnome : http://www.gnomedesktop.org/article.php?sid=1577(...)
Notez que je n'ai plus de nouvelles sur ce projet, mais il est bien intéressant. Utiliser vim dans Evolution, le rêve !!! :-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Intégrer Vim dans Gnome..
Posté par Mickael Marchand . Évalué à 3.
Si c'est juste faire apparaitre Vim dans une fenetre Gnome , on sait le faire dans KDE (cf le vimpart).
Mais c'est tellement inutile que c'est a en pleurer.
nous l'integration qu'on souhaite, c'est que l'application qui 'integre' le 'vim', puisse aussi 'utiliser' le vim pour pour par exemple la completion, le syntax highlight, les polices, bref que 'vim' devienne un outil et pas un pauvre truc qui se ballade dans une fenetre.
je te parle meme pas du mode 'multifenetre' que vim sait si bien gerer hein ;)
(alors vim dans kdevelop c'est top du coup ;)
d'ailleurs pour gnome, ils ont mis vim dans evolution, c'est bien, mais :
1 - qui l'utilise vraiment ?
2 - est-ce utilise dans autre chose que evolution ?
3 - si vous avez repondu non et non aux 2 questions precedentes, demandez-vous pourquoi ;)
Mik,
Yzis team ;)
[^] # Re: Intégrer Vim dans Gnome..
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Personne car c'est encore un patch qui n'a pas été intégré officiellement. Notons que selon Ximian il le sera dans la release qui suivra la 2.0.
2 - est-ce utilise dans autre chose que evolution ?
Le gars y travaille. Il veut arriver à faire un truc générique.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Intégrer Vim dans Gnome..
Posté par gnumdk (site web personnel) . Évalué à 3.
Comme on le voit sur le screenshot, seul la zone de saisie du mail utilise vim, pas les zone de saisie des adresses, etc...
En fait, ma question aux devels de Yzis, quand ils parlent de réutiliser des libs deja existantes, ce sont des libs indépendante de kde? En clair, est ce que dans deux ans Yzis sera tellement perdu au milieu de kdelibs que le projet sera totalement inutilisable par gnome par exemple? (comme kde en a si souvent l'habitude *). Il serait bien de pouvoir avoir Yzis dans Kde et dans Gnome mais je rêve un peut trop.
* => je rappelle que j'utilise Kde, ca evitera les moinssages de pros kde qui ne supportent pas la critique ;)
[^] # Re: Intégrer Vim dans Gnome..
Posté par ploum (site web personnel, Mastodon) . Évalué à -3.
Mais comme j'apprend que tu utilises KDE pour de vrai, ça mérite un moinssage !
ALLEZ HOP ! Gnome rUl3Z !
...
...
....
(PS : je l'ai pas vraiment fait hein !)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Intégrer Vim dans Gnome..
Posté par Mickael Marchand . Évalué à 4.
Yzis , c'est :
1 - une librairie 'core' basee sur Qt et Lua (pour le moment)
pour l'instant Qt3 mais avec Qt4 on devrait avoir un 'qt4 non-GUI' qui normalement sera une petite librairie (plus legere que le Qt actuel quoi)
2 - une appli 'kyzis' qui utilise la librairie precedente et les librairies KDE pour faire un composant et une jolie appli KDE
3 - une appli 'nyzis' qui utilise ncurses 5 pour avoir un 'yzis' en mode console
vu que libyzis utilise Qt, on a ainsi directement des choses comme l'unicode, les listes, les keycodes etc. Ca nous evite de reecrire 90% du code de Vim en gros et de nous concentrer sur les choses importantes (== les fonctionnalites ;)
a terme, on espere avoir un 'gyzis' qui utilisera gtk(+?) pour faire une jolie interface GTK/Gnome a yzis. L'ideal etant d'en faire d'abord un composant bonobo. La librairie 'core' fournit des interfaces generiques et independantes de KDE permettant ainsi de coder differentes GUIs au-dessus.
Nos objectifs sont donc :
1 - une librairie principale ou on fait tout le truc d'edition de texte dependante uniquement (et le moins possible) de Qt
2 - greffer des GUIs qui utilisent la librairie, apres c'est aux devels des GUIs de decider s'ils font ou non des composants reutilisables. kyzis fournit un kpart/ktexteditor pour pouvoir etre greffe dans kdevelop/quanta/etc...
donc s'il y a des volontaires pour une bonobofication de yzis, y a pas de probleme, suffit de coder et de nous contacter ;)
bien entendu, toutes les GUIs doivent 'linker' avec Qt vu que le composant de base c'est quand meme Qt, mais ca n'empeche nullement de faire une appli Gtk...
concernant Qt, on n'utilise qu'une tres faible partie de Qt dans le 'core', principalement les QStrings, QFile ... Que des trucs tres basiques. On attend donc impatiemment Qt4 :)
sinon peut meme avoir un yzis fait en motif, wxwindows, X ? , ...., tout ce qu'il faut c'est des volontaires pour les faire ;)
Mik
[^] # Re: Intégrer Vim dans Gnome..
Posté par eJah . Évalué à 2.
[^] # Re: Intégrer Vim dans Gnome..
Posté par gnumdk (site web personnel) . Évalué à 1.
Mais pour Qt4, la partie GUI et autre(QStrings, ...) sera séparé(comme la glib et gtk) si j'ai bien compris.
Donc, il sera dépendant d'un truc de trolltech. Mais Kde a deja des dépendances envers certaines parties de gnome(libcroco, glib, ...).
[^] # Re: Intégrer Vim dans Gnome..
Posté par Philippe F (site web personnel) . Évalué à 8.
On s'est mal compris sur la signification du mot integrer.
Avoir vim pour editer ses mails dans KDE, c'est possible depuis longtemp (mikmak avait fait un patch dans ce sens). Avoir vim en style KDE, pareil, c'est possible depuis longtemp. Ca revient juste a lancer un editeur au bon moment, il n'y a pas de contraintes particulieres.
Mainenant, si on veut integrer vim dans KDevelop ou dans Kate, on doit avoir:
- la possibilite d'afficher plusieurs fenetres independantes sur le meme texte
- la possiblite de gerer plusieurs fenetres independantes avec du texte different
- la notion de focus: ce n'est pas toujours l'editeur qui controle ce qui se passe
- la notion boucle d'evenement separee: l'editeur n'etant pas le maitre, il doit se laisser controler par l'application qui l'embarque.
Ces 4 points sont _impossibles_ a realiser avec vim, et ce independamment de KDE ou de Gnome.
Pour l'instant, les gens qui parlent d'integration dans Gnome / bonobo de vim parlent en fait de modifier l'application cible pour qu'elle puisse appeler explicitement le composant vim (type le patch evolution).
Pour KDE, on a un niveau d'abstraciton qui a ma connaissance n'est pas present dans Gnome: KDE definit un composant editeur generique, avec des notions de documents, vue, curseur, undo, ... Rentrer vim la-dedans implique de s'adapter a ces contraintes. Le resultat, c'est que n'importe quelle application KDE pourra utiliser vim, sans meme le savoir. L'utilisateur aura juste a declarer le kpart vim comme son kpart editeur prefere. Ca va beaucoup plus loin que patcher evolution. Notamment, les applications comme quanta ou kdevelop n'ont meme pas besoin d'etre patchee.
Voila pourquoi on peut avoir l'impression que l'integration de vim dans KDE est plus difficile que dans Gnome. C'est simplement qu'on va plus loin.
Les 4 points cites sont les plus bloquants pour utiliser vim en tant que composant graphique. Bien sur, je ne vous surprend pas en vous disant que yzis n'a pas ces limitations.
[^] # Re: Intégrer Vim dans Gnome..
Posté par k. stephane . Évalué à 4.
Le patch bonobo-vim fait de Vim un composant bonobo a part entiere. Ce composant devrait evoluer vers une implementation complete du composant "Editor".
Il a fallu patcher Evolution pour la raison suivante:
- Evolution bien que bati sur une architecture de composants n'est capable d'utiliser que un seul editeur, celui bien sur propose par ximian le GtkHtmlEditor version 3, il ne supporte meme pas Gedit, qui est l'editeur / le composant d'edition de base de Gnome. Le patch permet de selectionner son editeur, c'est tout.
Le patch bonobo-vim pretend creer un composant bonobo a partir de vim, avec esperons-le dans l'avenir, un support pour l'ouverture de fenetres (toplevel) multiples dans le meme processus et tout le reste.
Ce que Gnome demande de ses composants d'edition est moins complique que ce que veut KDE, en gros, il faut implementer:
BonoboControl
BonoboPersistStream
BonoboPersitsFile
et si on veut aller plus loin:
NautilusView
GnomeDesktoEditor (pas sur de celui-la).
En gros, c'est faisable, en hackant comme des bourrins le code gui-gtk.c de vim qui est degeulasse et plein de ifdefs...
Mais c'est faisable et cela peut nous donner un composant Gnome complet et fonctionnel, sans tout changer, donc sans ennuyer Bram.
Selon moi neanmoins, un fork serait bienvenu pour nettoyer tout ca et separer le moteur des interfaces.
Merci,
Stephane K.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.