Neovim est un fork tout récent (fin janvier 2014) de Vim. Faut-il rappeler ce qu'est Vim (Vi IMproved), le fameux éditeur de texte ? Lui-même clone le plus populaire de l'ancêtre Vi ?
Le logiciel a maintenant plus de 20 ans, contient environ 300 000 lignes de code de vieux C effrayant que peu de gens comprennent. Le mainteneur (unique ?) de Vim, Bram Moolenaar, refuse de factoriser certaines parties du code, et est très prudent avant d'accepter des patchs, car c'est lui qui devra en assurer la maintenance. Conséquence de tout ça : Vim est très dépendant d'une seule personne et évolue très lentement.
Neovim a pour objectif premier de simplifier la maintenance de vim :
- modernisation du système de compilation : utilisation de cmake ;
- suppression du code assurant la compatibilité avec de vieux systèmes ;
- utilisation d'une bibliothèque externe (libuv) pour s'abstraire des différences entre les systèmes d'exploitation ;
- factorisation « agressive » du code ;
- meilleure séparation du code entre différents développeurs.
Par la suite, un nouveau système de plugins est prévu, ainsi que la possibilité de pouvoir créer plus facilement des interfaces graphiques (à la manière des plugins).
NdM : merci à Carif pour son journal.
Pour les utilisateurs d'Arch Linux, neovim est disponible dans aur. La configuration et les plugins de vim sont compatibles (.neovimrc et .neovim/).
Une campagne de financement participatif est en cours sur Bounty Source. Elle a déjà atteint le premier objectif de 10 000 $ en à peine 48 heures !
Pour l'utilisateur final, neovim n'a actuellement pas d'intérêt particulier, mais il peut devenir à terme très intéressant :
- développement plus pérenne (ne repose pas sur une seule personne) ;
- correction de bugs et nouvelles fonctionnalités plus vite intégrées.
NdM : Si vous souhaitez apprendre ou vous améliorer sur Vim, il y a un cours sur OpenClassrooms. Enfin, si vous pensez être un gourou, allez donc faire un tour aux TupperVim parisiens qui ont lieu tous les mois chez Mozilla. De grands moments de Geekitude ! Testé et approuvé :-)
Aller plus loin
- Journal à l'origine de la dépêche (452 clics)
- Site du projet Neovim (quasi vide) (1055 clics)
- Neovim sur github (503 clics)
- Site web de Vim (323 clics)
- Vim sur OpenClassrooms (250 clics)
- Les TupperVim (326 clics)
# Emacs
Posté par Reihar . Évalué à -10.
Personnellement, j'utilise GNU Emacs sans interface graphique et je m'en porte bien.
[^] # Re: Emacs
Posté par dave_null (site web personnel) . Évalué à 9. Dernière modification le 26 février 2014 à 14:36.
Personnellement, j'utilise VsVim dans Microsoft Visual Studio 2013 avec Resharper et je m'en porte bien :-) [/troll]
Mais un Vim plus facile à intégrer dans les autres éditeurs est vraiment très intéressant.
[^] # Re: Emacs
Posté par Reihar . Évalué à 6.
C'est trop gros, ça passera pas mais je respecte la tentative.
[^] # Re: Emacs
Posté par ariasuni . Évalué à 0.
Emacs? :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Emacs
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 3.
Un vrai vim avec vimrc dans intellij ce serait orgasmic <3
[^] # Re: Emacs
Posté par Zylabon . Évalué à 2.
J'utilise emacs, mais avec interface graphique, j'aimerais m'en passer mais je ne sais pas comment.
Quand j'ai 4 buffer ouverts en même temps, c'est super chiant de passer de l'un à l'autre sans cliquette ou faut faire C-x o C-x o C-x o… Typiquement, le mode gdb ouvre 6 buffer entre lesquels ils faut naviguer.
J'ai le même problème avec mon gestionnaire de fenêtre tilling, mais j'ai moins de fenêtre que de je buffer emacs à l'écran, et je peux naviguer dans les deux sens, et je change moins souvent.
Donc tu fais comment ?
Please do not feed the trolls
[^] # Re: Emacs
Posté par vlamy (site web personnel) . Évalué à 2.
http://www.emacswiki.org/emacs/SwitchingBuffers :)
Un tiling WM qui ne permet pas de changer de fenêtre sans utiliser la souris !? Lequel est-ce ? Je veux un nom ! :)
Attention à explorer toutes les fonctionnalités d'un outil avant de troller.
[^] # Re: Emacs
Posté par Zylabon . Évalué à 4. Dernière modification le 26 février 2014 à 17:04.
Rha c'était pas du trollage :)
Xmonad permet bien entendu d'utiliser la souris. Mais avec le clavier, avec n pressions de couche + 1 (la touche super) je peux avancer (ou reculer) le focus n dans l'anneau de fenêtre, c'est plus rapide que la souris.
J'ai bien cherché comment en faire avec emacs, mais devant le genre de lien que tu m'a envoyé, j'ai une crise de procrastination : une cinquantaines de solutions avec une description laconique, pas forcement maintenues, pas forcement compatible avec toutes les versions d'emacs. Bref… fleeeeeemme.
Mais bon, quand la curiosité bat la flemme :
problème réglé ! (jusqu'a ce que j'ai envie d'utiliser ces raccourcis pour xmonad…)
Please do not feed the trolls
[^] # Re: Emacs
Posté par vlamy (site web personnel) . Évalué à 3.
En plus ce n'est pas changer de buffer que tu veux, c'est changer de « sous-fenêtre » Emacs, ce qui est différent :)
Content que ton problème soit réglé :)
[^] # Re: Emacs
Posté par Louis Roché (site web personnel) . Évalué à 2.
Quelque chose comme ça non ?
[^] # Re: Emacs
Posté par Thomas Etcheverria . Évalué à 1.
Pour changer de fenêtre perso j'utilise switch-window : https://github.com/dimitri/switch-window
Ça marche pas mal du tout :
C-x O puis le numéro qui correspond à la frame attendue.
[^] # Re: Emacs
Posté par François (site web personnel) . Évalué à 1.
Ou encore winswitch que je trouve pas mal mais demande un peu de gymnastique
http://www.emacswiki.org/emacs/WinSwitch
# Et XDG_CONFIG_DIR ?
Posté par jcdubacq . Évalué à 7.
Un vim pour le 21e siècle, et toujours pas capable de stocker sa configuration dans ~/.config ?
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par machmalabala . Évalué à 1.
J'avoue que ça fait un peu tâche…
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par misaflo (site web personnel) . Évalué à 4.
Ça viendra peut être : https://github.com/neovim/neovim/issues/78
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par riri le breton (site web personnel) . Évalué à 6.
export VIMDIR="$XDG_CONFIG_DIR/vim"
export VIMINIT="source '$XDG_CONFIG_DIR/vim/vimrc'"
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par erdnaxeli (site web personnel) . Évalué à 0.
Ce n'est pas une bonne solution. S'il y a des standards, ce n'est pas pour se taper la config pour chaque logiciel.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par Philippe F (site web personnel) . Évalué à 4.
Et quand le standard arrive 20 ans après l'existence du logiciel, c'est quand même petit de le critiquer.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par Antoine . Évalué à 10.
Ben oui, d'ailleurs Firefox et consorts refusent d'implémenter les dernières normes du Web : ils sont arrivés avant.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Euh, en fait non. Les dernières « normes » du Web sont écrites à partir des expérimentations des différents navigateur. Il n'y a qu'à voir XmlHttpRequest par exemple.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par anaseto (site web personnel) . Évalué à 2.
Vu que vim peut être utilisé indépendamment d'un desktop sous X, et ne rentre donc pas spécialement dans le cadre des objectifs du XDG, je me demande si on doit voir un lien entre vim et ce standard, dont l'objectif principal n'est pas l'intégration de logiciels qui existaient avant Xorg.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par ariasuni . Évalué à 8.
Donc ça gêne personne le bordel dans
~? Et puis c’est pas réservé aux applications qui tournent sous X.org (ou Wayland), vu que PulseAudio et enchant (et sûrement des tas d’autres, mais j’ai pas beaucoup d’applications installées) y stockent leur configuration.Et certaines applications qui tournent sous X.org n’y logent pas leur configuration: on a des trucs genre Java, Flash, Pidgin, Netbeans, Eclipse, Opera, Steam, etc.
Et t’as ceux qui sont aux deux endroits (ex: Skype).
Et t’as ceux qui ont un répertoire spécial:
.mozillapour Firefox, Thunderbird et compagnie (pour que ça comme sous Windows d’après ce que j’ai compris),.kde4pour KDE (ce qui n’est pas très gênant finalement, si les applications individuelles ne continuaient pas à créer du bordel dans~).Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par Anonyme . Évalué à 0.
Tu preferes du bordel dans ~/.config ?
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par ariasuni . Évalué à 9.
Oui.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par Moonz . Évalué à 2.
http://ordiluc.net/fs/libetc/
https://github.com/sloonz/rewritefs
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par ariasuni . Évalué à 0.
Ce sont des bidouillages…
LD_PRELOADc'est moche, ça peut rendre certaines applications instables.ls.Sinon peut-être qu'on fait des programmes qui respectent les normes par défaut.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par Moonz . Évalué à 2. Dernière modification le 28 février 2014 à 10:55.
Pas de commit parce qu’il fait le job et que je n’ai eu aucun bug :)
Qu’est-ce que tu as contre FUSE ? IMO c’est le truc le plus utile pour le desktop qu’ait fait le noyau depuis udev (et je regrette très fort que ce soit pas plus utilisé)
Pas en fonctionnement normal non. Ça arrive seulement quand tu as des dotfiles que tu n’as pas déplacés dans
.config/La FAQ n’est pas assez claire ? Ce serait l’occasion d’un commit, remarque :)
Ce serait la solution parfaite bien sûr, mais malheureusement c’est déjà ce qu’on me disait en 2008 quand j’ai repris libetc… Il faut bien une solution en attendant.
[^] # Re: Et XDG_CONFIG_DIR ?
Posté par ariasuni . Évalué à 0.
Certes, c'est un indicateur comme un autre. J'ai tendance à pas utilises les trucs qui prennent la poussière par peur que ça ne fonctionne plus un jour ou qu'on ne corrige pas les bugs.
Ça me parait un peu overkill, c'est tout. ^^
C'est vrai.
Bah pour occuper mon week-end je vais faire des rapports de bug. :p
Écrit en Bépo selon l’orthographe de 1990
# citation des commentaires du journal
Posté par bobo38 . Évalué à 2. Dernière modification le 26 février 2014 à 17:03.
« C'est presque une maladie dans l'informatique ça. De considérer qu'un logiciel fini est un logiciel mort. » source : http://linuxfr.org/nodes/101355/comments/1522534
J'ai trouvé cette remarque très pertinente… En tant qu'utilisateur de vim, je ne vois aucune fonctionalité supplémentaire à ajouter. Faire du réarrangement de code, dans quel but ?
Il y avait pas mal de commentaires dans ce sens dans le journal, avant qu'il ne soit promu au rang de dépêche.
[^] # Re: citation des commentaires du journal
Posté par jihele . Évalué à 2.
Moi je ressens parfois des manques, mais c'est sans doute parce que je sais pas le paramétrer.
Par exemple, j'aimerais bien avoir des onglets dans gvim ou vim, quand j'ai plusieurs fichiers ouverts. Je crois que c'est possible, j'ai essayé une fois sans succès et ça m'a jamais assez manqué pour que j'insiste. Si c'était pas défaut, je m'en servirais.
Les autres problèmes sont plus des questions d'intégration : coloration syntaxique, ctags, etc, qui font que c'est pas aussi immédiatement pratique qu'un IDE.
[^] # Re: citation des commentaires du journal
Posté par zul (site web personnel) . Évalué à 3.
vim -p list_fichier
:help tabpage
De rien :).
[^] # Re: citation des commentaires du journal
Posté par PiT (site web personnel) . Évalué à 2.
J'ai cherché jadis … -p
http://namok.be/blog/?post/2007/03/23/121-vim7-tabs
[^] # Re: citation des commentaires du journal
Posté par jihele . Évalué à 3.
Super. Merci.
Et si je veux que les nouveaux fichiers s'ouvrent dans la même fenêtre gvim, apparemment, il n'y a pas l'option pour, mais je peux me faire un
et lancer gvir (idem pour vim).
Bonne soirée !
[^] # Re: citation des commentaires du journal
Posté par PiT (site web personnel) . Évalué à 1.
Ton alias te permets d'ouvrir un fichier à partir de ta console mais tu peux également l'ouvrir à partir de vim lui-même
[^] # Re: citation des commentaires du journal
Posté par bobo38 . Évalué à 0.
Pour les onglets il y a aussi l'émulateur de terminal. Les konsole, gnome-terminal, xfce-terminal, terminator, urxvt font tous ça. Pour les copier-coller entre onglets, tu peux utiliser le surlignage plus click milieu, il y a aussi des méthodes pour passer par le presse-papier système.
[^] # Re: citation des commentaires du journal
Posté par saimn . Évalué à 6.
Plutôt que d'avoir plusieurs instances de vim, je l'utilise aujourd'hui principalement en mode IDE:
- une seule instance pour tout ouvrir,
- ctrlp pour ouvrir facilement les fichiers, switcher entre les buffers, naviguer dans les tags (avec ctags), …
- des onglets quand le besoin s'en fait sentir,
- plein d'autres trucs, largement basé sur la config de Steve Losh:
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
https://bitbucket.org/sjl/dotfiles/src
Une capture pour donner une idée: http://lut.im/cJas0lz0
[^] # Re: citation des commentaires du journal
Posté par PiT (site web personnel) . Évalué à 1.
Intéressant ton screenshot … un gVim « à la SublimeText » voilà qui me donne envie de lire plus avant ;-)
[^] # Re: citation des commentaires du journal
Posté par riba . Évalué à 9.
Et bien tant mieux pour toi! Vim ne gère pas les vues multiples, c'est-à-dire plusieurs instance/thread/whatever de vim dans des terminaux différents qui manipulent les mêmes buffers, où la modification sur l'un des terminaux impacte les autres. Kate & Emacs le font. En mode multi écran vim est une horreur (il faut se souvenir du "dernier" vim qui a écrit le fichier, faire du :e! et cie…). C'est dans la TODO list d'après mes dernières recherches, mais vu le passif du code, il faudra des années (c'est pas moi qui le dit mais je ne retrouve plus le lien).
Dès que le mode vi de kate est compatible avec tout mes plugins, je switcherai.
vim est loin d'être fini, il manque le support de TrueColor aussi d'ailleurs (oui, il existe des terminaux compatible et c'est joli™).
[^] # Re: citation des commentaires du journal
Posté par bobo38 . Évalué à 3.
Ouverture multiple du même fichier, c'est un cas d'utilisation assez particulier mais je comprends. Personnellement, le fait d'avoir un message disant que le fichier est déjà en édition ailleurs ne m'a pas choqué jusque-là (je trouve ça plutôt pratique, KISS).
C'est quoi cette histoire de TrueColor ? Ça a un rapport avec la réaffectation des couleurs dans le terminal (on n'est pas obligé d'utilisé xterm) ? Gvim ne propose-t-il pas le support de thèmes de couleur différent en 24 bits (je ne retrouve plus un site web qui offrait la possibilité d'en créer un soi-même) ?
[^] # Re: citation des commentaires du journal
Posté par riba . Évalué à 6.
oui les messages qui testent la présence d'un .swp et alertent sur la possible perte de données c'est bien, mais quand tu en as plein tout le temps à cause de ton mode d'utilisation de vim, tu te fais vite avoir à force de les "fermer" de façon systématique (et perd un jour vraiment des données).
Vim ne gère que 256 couleurs, alors que de plus en plus de terminaux en gère 2**24 (aka TrueColor). Un patch (non encore mergé et surement jamais) permets ça, et autorise des vrais colorscheme (comme ceux-là ). Mon terminal le gère et je sais que le colorscheme n'est pas optimal en 256 couleurs (solarized). Gvim n'est pas un option pour moi (travail en mode terminal uniquement)
[^] # Re: citation des commentaires du journal
Posté par bobo38 . Évalué à 1.
Merci pour les explications. Quand je pense à la bonne proportion de mes collègues qui utilisent leur terminal en monochrome (xterm la plupart du temps) et éditent leurs fichiers texte avec nedit. Et je ne parle pas de ceux qui vérifient des fichiers texte avec more ;)
Pour les couleurs, il est possible de modifier les 16 couleurs du terminal que vim utilise. Sur gnome-terminal (Redhat 5.4), c'est dans le menu Edit -> Current Profile, onglets Colors, ensuite tu cliques sur la couleur qui te dérange et tu as une GUI pas mal avec un triangle rotatif pour définir la couleur sur lequel tu sélectionnes un point entre cette couleur le noir et le blanc (contraste/luminosité). Par exemple le jaune c'est #FFFF55, (6×4bits=24bits, si je ne m'abuse).
[malife]Avec ça j'ai pu convertir un ancien collègue daltonien au terminal à fond foncé avec un texte d'une couleur adaptée et un prompt d'une couleur différente bien tranchée (pour qu'il conserve sa manie du path absolue). Bien plus confortable.[/malife]
[^] # Re: citation des commentaires du journal
Posté par Juke (site web personnel) . Évalué à 2.
C'est pas le role de tmux/screen ça ?
[^] # Re: citation des commentaires du journal
Posté par riba . Évalué à 2.
heuhhh, non.
Tous mes vim sont dans des tmux mais ça ne change rien du tout au problème car il n'y a qu'un "curseur" actif à la fois, la base du problème. La feature que je décris qui me manque est un peu comme le multi-pointer pour XFreee86: possible mais il faut réecrire beaucoup de truc.
[^] # Re: citation des commentaires du journal
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Si tu lisais la ML des devs de vim, tu verrais qu'il y a beaucoup de choses que les gens veulent rajouter. Les exemples classiques sont "une gestion correcte des entrées" pour pouvoir distinguer et par exemple, ou des communications asynchrones avec des processus externes (pour intégrer des interprètes ou débuggueurs). J'adorerais avoir les deux…
# Sans troller, question !
Posté par yeahman . Évalué à 5.
Salut,
J'ai une petite question quand même.
Si je capte tout bien, l'équipe de SublimeText avait commencé par développer un plugin sur Vim avant de passer à une version standalone.
Je sais que des gens l'utilisent même si c'est du proprio payant (utilisation gratuite possible quand même cependant).
Quels sont vous retours par rapport à Vim du coup ? Pourquoi sont-ils partis sur du standalone et du proprio (si quelqu'un sait) ?
Merci
# et pour le 3ieme millenaire
Posté par modr123 . Évalué à -2.
on ferat quoi ?
[^] # Re: et pour le 3ieme millenaire
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Jean Ferrat ce qu'il veut, mais on fera autre chose.
[^] # Re : et pour le 3ieme millenaire
Posté par _jordan_ . Évalué à 1.
Jean Ferrat plus grand chose malheureusement. Petit hommage à cet homme.
# 300 000 lignes de code !
Posté par elboulangero (site web personnel) . Évalué à 1.
Sérieux, 300 000 lignes de code ça me parait assez énorme pour un éditeur de texte en console, non ?
Je connais pas la taille des projets sur lesquels vous travaillez, mais moi perso j'en arrive gentillement à 140 000 lignes. Ca permet de faire beaucoup de choses déjà ! Alors consacrer 300 000 lignes juste pour un éditeur de texte, ça me parait fou comme truc. Cela dit, si Bram Moolenaar est tout seul à maintenir ces 300 000 lignes, alors je comprends qu'il soit pas chaud chaud pour toucher à quoi que ce soit.
Question annexe: je serai curieux de connaître la taille des codes sur lesquels vous travaillez !
[^] # Re: 300 000 lignes de code !
Posté par fearan . Évalué à 2. Dernière modification le 27 février 2014 à 17:45.
$>wc -l $( find -iname *.cc )
767828
par contre le coté java est plus prolixe
$> find . -iname *.java -exec cat {} \; | wc -l
1094898
trois fois rien quoi (oui j'ai omis les .h et .hpp (template) ;)
j'ajouterai que je ne compte pas les scripts (y'en a un bon nombre aussi, ni les xml de conf, dont certains sont pas loin d'être du code aussi)
Mon projet précédent faisait dans les 3 000 000, c++ / Python ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: 300 000 lignes de code !
Posté par fearan . Évalué à 5.
Pour un éditeur de texte comme le bloc-note windows ou ed, oui, pour un éditeur tel que vim ou emacs, ça ne me surprend guère.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: 300 000 lignes de code !
Posté par randruc . Évalué à 1.
C'est même relativement peu… Je suis surpris, j'aurais dit davantage.
[^] # Re: 300 000 lignes de code !
Posté par lolop (site web personnel) . Évalué à 10.
Surtout qu'en bash on fait la même chose en une ligne:
$ vimPython 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: 300 000 lignes de code !
Posté par Zylabon . Évalué à 3.
On peut ajouter 150 000 lignes de vim script.
Please do not feed the trolls
[^] # Re: 300 000 lignes de code !
Posté par Zylabon . Évalué à 2.
(trop tard pour éditer) À titre de comparaison emacs 24 c'est :
Please do not feed the trolls
[^] # Re: 300 000 lignes de code !
Posté par saltimbanque (site web personnel) . Évalué à 2.
bah vi mais en voyant le nombres de modes inclus d'emblée. Genre org mode.
[^] # Re: 300 000 lignes de code !
Posté par barmic . Évalué à 3.
Vraiment ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 300 000 lignes de code !
Posté par Zylabon . Évalué à 2.
cloc ne regarde que les extensions on dirait. Il y a un fichier tutorial.cs, le tuto tchèque à priori :)
Please do not feed the trolls
# Vin ?
Posté par Francois Revol (site web personnel) . Évalué à 2.
Alors il faut l'appeler "vin" (Vi Neo), en plus le n est juste après le m dans l'alphabet…
Hein, quoi ? Non je ne bois pas d'alcool moi, c'est pas mon problème le lobby viticole !
# kakoune, un genre de neovim, mais en mieux ?
Posté par nojhan (site web personnel, Mastodon) . Évalué à 2.
J'ai vu fonctionner kakoune, un éditeur de texte très inspiré de vim, et c'est vraiment pas mal.
Les killers features que j'aime bien sont la grammaire dans le bon ordre (« sélection, puis action », alors que vim fait « action, puis sélection ») et le remplacement d'un langage de script par un petit système d'exposition des variables (ce qui fait que vous pouvez utiliser le langage que vous voulez, par exemple bash).
Il y a notamment pas mal de trucs que neovim veux implémenter, mais qui, là, sont déjà faites. Et c'est en… C++11.
https://github.com/mawww/kakoune
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.