L’éditeur Vim 9.0 est disponible depuis peu, avec une série de petites améliorations çà et là. Mais il contient également un apport majeur, sous la forme d’un langage de script clairement conçu pour les performances.
Baptisé Vim9, ses commandes sont compilées en instructions. Le résultat est une multiplication de la vitesse de traitement par 10 à 100 selon les cas, rien que ça. La structure évite autant que possible des formes propres à Vim pour se rapprocher davantage de ce qui se fait dans JavaScript et TypeScript.
Malheureusement, cela concerne surtout les nouveaux scripts, car les importants changements entrepris cassent la compatibilité dans certains domaines.
Commentaires (28)
#1
Toujours bien de voir que cet éditeur trentenaire continue de s’améliorer. Il peut toujours paraître austère et compliqué (et le nombre de meme qui circulent sur “j’arrive pas à fermer vim” est un peu aussi un témoignage de ce point), mais quand on commence à apprendre à s’en servir… Bordel qu’il est puissant et efficace.
#1.1
j’alterne entre vim et nano selon le besoin, les 2 ont leurs avantages et inconvénients ^^
Mais faut avouer que vim au début, les commandes ne sont pas du tout instinctives, déjà quand tu édites, tu peux pas modifier direct, c’est pas très naturel :)
#1.2
Et d’un autre côté, je ne compte pas le nombre de mails que j’ai envoyés où la dernière ligne était un :wq
#2
Emacs !
#2.1
Ah non ! Pas Emacs !
C’est un coup à se retrouver perclus d’arthrose dans les mains ça !
#3
https://www.commitstrip.com/fr/2017/05/29/trapped/
#4
Alors que Neovim a adopté Lua depuis un moment déjà, qui est un langage bien implanté.
#5
Ça dépend de ton parcours informatique.
Quand comme moi, tu as appris l’informatique sur un terminal papier (de type télétype) avec un éditeur ligne où quand tu devais modifier une ligne, il fallait la retaper et que toute commande d’édition ressemblait aux commande en mode “ex” de vi/vim avec des numéros de ligne et que tu es passé plus tard sur des systèmes Unix avec des terminaux caractères (type VT100) en utilisant vi, tu n’as aucun problème avec vim.
J’ai utilisé Windows après Unix.
Même si je l’utilise moins, je garde toujours les réflexes.
#6
Le problème de vim (et d’un tas de logiciels) c’est qu’il ne prend pas en compte la position des touches du clavier en fonction de la disposition choisie (azerty/qwerty/bépo), mais de sa «valeur», du coup c’est ultra chiant à configurer et pour switcher.
#6.1
Ben, à part hjkl, t’es pas censé changer le reste, justement parce que ce qui compte c’est la valeur et pas la position (y pour yank, w pour word, q pour quit, i pour insert, etc).
Après hjkl peut provoquer des conflits une fois remappé, et c’est un peu plus chiant du coup. Perso je me suis simplement mis à utiliser les flèches (qui sont pas loin sur mon clavier custom) ^^’
#6.2
Mais tu perds toute la facilité des commandes n’utilisant pas des lettres (et t’en as plein utiles, les chiffres, ^ $ * ‘ { } [ ] …..
On voit que vi(m) est vraiment configuré pour les claviers qwerty. Et du coup même en reconfigurant tous les bindings (ce qui perd la compatibilité avec vi(m) sur un autre poste), il faut revoir la logique des bindings, et azerty n’a pas les parenthèses/crochets/accolades à coté l’une de l’autre par exemple donc faut faire autrement.
C’est la seule chose qui me gène sur cet éditeur. Mais avec tous les avantages qu’il a, je fais avec :)
#6.3
Ben, justement, pour ces trucs-là, le Bépo est plus pratique que l’Azerty, je trouve les symboles bien mieux placés. Après comme c’est prévu pour le Qwerty t’as ptêt quelques trucs pas idéaux, comme les chiffres pas en accès direct, effectivement, mais bon à l’usage… et puis c’est déjà le cas en azerty, et perso j’ai jamais utilisé de qwerty de façon régulière. Donc bon quoiqu’il arrive passer d’azerty à bépo était un progrès.
#6.4
Jamais testé le BEPO donc je me prononcerai pas sur l’adaptation en tant que développeur (j’avais lu que c’était pas top, mais je n’en sais rien moi même).
En revanche ce qui me bloque (même pour passer au nouvel azerty ou au qwerty), c’est que j’ai un fixe, un laptop, et un mac pro, et que donc si je passe le fixe sur un autre format, je devrais jongler avec l’azerty du laptop et le “machin” du mac…
C’est plus simple pour moi de me faire une raison !!
#7
Ca fait des siécles que je n’ai plus lancé vim ou vi.
nano suffit amplement à mes besoins et est bien plus naturel.
#7.1
Ouais, pareil. Vim j’ai essayé plein de fois, mais j’en ai pas un usage assez poussé pour m’y accrocher. Je l’utilise encore parfois pour pas perdre la main, mais bon.
#8
Vim ? C’est un fork d’emacs ?
#8.1
un jour, faudra que j’apprenne a utiliser emacs…
mais la greffe d’un 3ème bras coûte cher
#9
Il l’est.
Je suis bien d’accord. Ça m’avait scié au début.
Ah je n’ai pas connu ça, pourtant suis plus tout jeune.
En fait j’ai connu les éditeurs pleine page (Mac, Turbo Pascal ou Amiga) avant de connaître Unix et j’ai été estomaqué de la pauvreté du “vi” de l’époque (début 90), où même sur certaines stations ou certains terminaux, les touche de curseur n’avaient pas d’effet (ou pire écrivaient une séquence d’échappement), ou bien la touche “Del”
.
J’ai aussi eu des collègues qui en 1995 utilisaient un “vi” très rudimentaire sur des stations Sun Sparc, alors que SunOS/Solaris disposait d’un éditeur pleine page qui était plutôt pas mal pour l’époque. Dire que dans l’entreprise en question on avait un type dont le poste comportait “méthodes et outils” et qui n’a jamais prêté attention à ça (j’ai rien dit mais ça me navrait en plus d’être incompréhensible de ne pas chercher à améliorer l’efficacité des équipes).
Pourtant Emacs existait déjà et était puissant, mais pas toujours disponible (snif). Sur Amiga 500 vers 1990 il existait même une version réduite appelée MicroEmacs qui était correcte.
C’est vrai que “nano” est trop peu connu, d’ailleurs c’est il y a à peine quelques années via NXI que j’ai appris son existence, je l’ai essayé pour voir.
#10
Vim reste l’éditeur que j’utilise, ne serait-ce que pour les commandes sed.
Je le trouve par ailleurs très puissant et je n’ai jamais eu de souci à basculer entre les différents modes et j’apprécie beaucoup sa grammaire. cw pour change word, c$ pour changer jusque la fin de ligne…
#10.1
C’est globalement mon utilisation aussi. Changer en masse des informations et les nombreux raccourcis clavier pour agir sur une lettre, un mot, une ligne, c’est vraiment puissant une fois qu’on les a intégré.
Bon, par contre, même s’il dispose d’un support de ces langages, ceux basés sur l’indentation comme Python ou le format YAML peuvent être vite assez relous à traiter avec vim.
#10.2
Quels soucis as-tu avec les langages à indentation ? Normalement, il n’y a aucun blocage par défaut avec ces langages, Et l’auto-indent fonctionne très bien.
#10.3
Disons que l’aide visuelle d’un éditeur à la Visual Code (avec les extensions kivonbien il afficher ça de façon colorisée) m’assiste beaucoup pour le coup pour mieux suivre à quel niveau j’en suis. Peut-être qu’il existe une astuce dans vim ça me surprendrai pas, mais je la connais pas pour le coup.
#10.4
syntax enable
filetype plugin indent on
dans ton ~/.vimrc ne te donne pas un résultat satisfaisant ?
#10.5
Ca permet en effet d’avoir une bonne assistance sur l’indentation, mais j’aime bien l’aide visuelle de ce genre là pour la lecture :
Ca m’aide souvent pour trouver la ligne mal indentée qui merdoie
Ca j’avoue que j’ai jamais trouvé si c’était disponible.
#10.6
Ya des plugins sympas pour ça !
j’utilise indentline qui me plait bien, mais je sais qu’il y en a d’autres.
https://github.com/Yggdroot/indentLine
#10.7
Merci !
bookmarked
#11
Je pense qu’effectivement notre parcours influence pas mal nos préférences. J’ai personnellement beaucoup de mal avec Vim et Emacs, car je suis habitué aux UI plus graphique des années 90. Comme beaucoup ici, si je dois faire une rapide édition et que je suis dans une console, Nano fait largement le taf. Pour le reste, je vais me tourner vers des logiciels avec une UI plus moderne, Kate/Gedit/Notepad++ ou VScode. Dans mon usage, je ne vois pas l’utilité de Vim et Emacs qui font doublon avec les outils que j’utilise et que je connais. Je ne sais pas les utiliser, et je n’ai pas le besoin de faire des effort pour l’apprendre. Ils sont peut-être cool, mais les outils que j’utilise le sont aussi. Et je suis sûr que dans le futur, il y aura de nouveau outils qui seront aussi très bien qui correspondront plus au nouveaux standards d’UI et je serais le vieux con qui dira que de toute façon, VScode c’est trop de la balle et qu’il est meilleurs que leur trucs.
#12
C’est le principe d’une version majeure.