Neovim : une refonte de vim pour le 21è siècle

Posté par . Édité par Florent Zara, BAud et Benoît Sibaud. Modéré par Ontologia. Licence CC by-sa
Tags :
38
26
fév.
2014
Technologie

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 ?

Logo VIM

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é :-)

  • # Emacs

    Posté par . Évalué à -10.

    Personnellement, j'utilise GNU Emacs sans interface graphique et je m'en porte bien.

    • [^] # Re: Emacs

      Posté par (page perso) . Évalué à 9. Dernière modification le 26/02/14 à 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 . Évalué à 6.

        C'est trop gros, ça passera pas mais je respecte la tentative.

      • [^] # Re: Emacs

        Posté par (page perso) . Évalué à 0.

        Mais un Vim plus facile à intégrer dans les autres éditeurs est vraiment très intéressant.

        Emacs? :p

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Emacs

        Posté par (page perso) . Évalué à 3.

        Un vrai vim avec vimrc dans intellij ce serait orgasmic <3

    • [^] # Re: Emacs

      Posté par . É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 (page perso) . Évalué à 2.

        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.

        http://www.emacswiki.org/emacs/SwitchingBuffers :)

        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.

        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 . Évalué à 4. Dernière modification le 26/02/14 à 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 :

          (global-set-key [s-left] 'windmove-left) 
          (global-set-key [s-right] 'windmove-right) 
          (global-set-key [s-up] 'windmove-up) 
          (global-set-key [s-down] 'windmove-down)
          

          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 (page perso) . Évalué à 3.

            Mais bon, quand la curiosité bat la flemme :

            (global-set-key [s-left] 'windmove-left)
            (global-set-key [s-right] 'windmove-right)
            (global-set-key [s-up] 'windmove-up)
            (global-set-key [s-down] 'windmove-down)

            problème réglé ! (jusqu'a ce que j'ai envie d'utiliser ces raccourcis pour xmonad…)

            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 (page perso) . Évalué à 2.

        Quelque chose comme ça non ?

        (global-set-key (kbd "M-S-<up>") 'enlarge-window)
        (global-set-key (kbd "M-S-<down>") 'shrink-window)
        (global-set-key (kbd "M-S-<right>") 'enlarge-window-horizontally)
        (global-set-key (kbd "M-S-<left>") 'shrink-window-horizontally)
        (global-set-key (kbd "M-<up>") 'windmove-up)
        (global-set-key (kbd "M-<down>") 'windmove-down)
        (global-set-key (kbd "M-<right>") 'windmove-right)
        (global-set-key (kbd "M-<left>") 'windmove-left)
        
      • [^] # Re: Emacs

        Posté par . É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.

  • # Et XDG_CONFIG_DIR ?

    Posté par . É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 . Évalué à 1.

      J'avoue que ça fait un peu tâche…

    • [^] # Re: Et XDG_CONFIG_DIR ?

      Posté par . Évalué à 4.

    • [^] # Re: Et XDG_CONFIG_DIR ?

      Posté par (page perso) . Évalué à 6.

      export VIMDIR="$XDG_CONFIG_DIR/vim"
      export VIMINIT="source '$XDG_CONFIG_DIR/vim/vimrc'"

      • [^] # Re: Et XDG_CONFIG_DIR ?

        Posté par (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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: .mozilla pour Firefox, Thunderbird et compagnie (pour que ça comme sous Windows d’après ce que j’ai compris), .kde4 pour 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 . Évalué à 0.

                Donc ça gêne personne le bordel dans ~?

                Tu preferes du bordel dans ~/.config ?

                • [^] # Re: Et XDG_CONFIG_DIR ?

                  Posté par (page perso) . Évalué à 9.

                  Oui.

                  • Pour les utilisateurs finaux, quand les fichiers cachés sont affichés c’est beaucoup moins le bordel dans le dossier de l’utilisateur (donc même s’il l’affiche sans faire exprès c’est pas très grave, alors que là maintenant c’est horrible)
                  • si on veut copier toutes ses configurations, il suffirait de copier le .config. Aujourd’hui il faut sélectionner les fichiers/dossiers à la main… Sans compter que si d’autres s’ajoutent il faudra modifier ton script, super.

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Et XDG_CONFIG_DIR ?

                    Posté par . Évalué à 2.

                    • [^] # Re: Et XDG_CONFIG_DIR ?

                      Posté par (page perso) . Évalué à 0.

                      Ce sont des bidouillages…

                      • libetc: ne fonctionne pour les programmes statiques, plus maintenu depuis 2008, LD_PRELOAD c'est moche, ça peut rendre certaines applications instables.
                      • rewritefs: Un module FUSE, Sérieux? Pas de commit depuis 2 ans, ça semble engendrer des comportements bizarres avec 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 . Évalué à 2. Dernière modification le 28/02/14 à 10:55.

                        Pas de commit depuis 2 ans

                        Pas de commit parce qu’il fait le job et que je n’ai eu aucun bug :)

                        Un module FUSE, Sérieux?

                        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é)

                        ça semble engendrer des comportements bizarres avec ls

                        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 :)

                        Sinon peut-être qu'on fait des programmes qui respectent les normes par défaut.

                        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 (page perso) . Évalué à 0.

                          Pas de commit parce qu’il fait le job et que je n’ai eu aucun bug :)

                          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.

                          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é)

                          Ça me parait un peu overkill, c'est tout. ^^

                          Pas en fonctionnement normal non. Ça arrive seulement quand tu as des dotfiles que tu n’as pas déplacés dans .config/

                          C'est vrai.

                          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.

                          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 . Évalué à 2. Dernière modification le 26/02/14 à 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 . É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 . Évalué à 9.

      En tant qu'utilisateur de vim, je ne vois aucune fonctionalité supplémentaire à ajouter.

      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 . É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 . É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 . É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 (page perso) . Évalué à 2.

        C'est pas le role de tmux/screen ça ?

        • [^] # Re: citation des commentaires du journal

          Posté par . É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 (page perso) . É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 . É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 . Évalué à -2.

    on ferat quoi ?

  • # 300 000 lignes de code !

    Posté par (page perso) . É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 . Évalué à 2. Dernière modification le 27/02/14 à 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 . Évalué à 5.

      300 000 lignes de code ça me parait assez énorme pour un éditeur de texte en console, non

      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 . Évalué à 1.

        C'est même relativement peu… Je suis surpris, j'aurais dit davantage.

        • [^] # Re: 300 000 lignes de code !

          Posté par (page perso) . Évalué à 10.

          Surtout qu'en bash on fait la même chose en une ligne:

          $ vim

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: 300 000 lignes de code !

          Posté par . Évalué à 3.

          On peut ajouter 150 000 lignes de vim script.

          vim 7.4 c'est (d'après cloc) :
          
          -----------------------------
          Language        ligne de code
          -----------------------------
          C                      285824
          vim script             145700
          C/C++ Header            19955
          Bourne Shell            13101
          IDL                      3886
          make                     2761
          C++                      2706
          Perl                     1143
          awk                       716
          Verilog-SystemVerilog     476
          C#                        458
          Objective C               118
          Assembly                  114
          DOS Batch                  80
          XML                        68
          Python                     37
          Teamcenter def             32
          C Shell                     7
          -----------------------------
          SUM:                   477182
          -----------------------------
          

          Please do not feed the trolls

          • [^] # Re: 300 000 lignes de code !

            Posté par . Évalué à 2.

            (trop tard pour éditer) À titre de comparaison emacs 24 c'est :

            ---------------------------------
            Language                     code
            ---------------------------------
            Lisp                      1144271
            C                          235596
            Bourne Shell                25419
            C/C++ Header                21176
            m4                          11199
            Objective C                 10145
            HTML                         1636
            Perl                         1264
            XML                          1034
            DOS Batch                    1008
            Verilog-SystemVerilog         861
            C#                            770
            awk                           477
            make                          285
            Patran Command Language       188
            Bourne Again Shell             66
            ---------------------------------
            SUM:                      1455395
            ---------------------------------
            

            Please do not feed the trolls

  • # Vin ?

    Posté par (page perso) . É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 (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.