Journal Helix, une excellent alternative à vim !

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
31
29
oct.
2024

Pour écrire du code, j'ai toujours été tiraillé entre les éditeurs de texte et les EDI. Il manque souvent aux éditeurs de texte des fonctionnalités qui doivent être ajoutées via des plugins, tandis que les EDI sont souvent beaucoup trop « usine à gaz », à tel point parfois que ça peut être dangereux quand il s'agit d'utiliser des fonctionnalités qu'on ne comprend pas bien.

J'ai commencé à utiliser vim il y a un moment déjà, et j'appréce sa nature modale (un mode pour insérer du texte, un mode pour sélectionner le texte, un mode pour modifier la sélection). Cependant, sans ajouter moult plugins, je le trouvais un peu dur à utiliser pour travailler sur du code (par exemple, il n'est par défaut pas possible d'accéder à la définition de la fonction qui se trouve sous le curseur). Quand on commence à plonger dans la myriade de plugins disponibles, il est facile de s'y perdre, et pour l'utilisateur frugal et fainéant que je suis, c'était trop galère à gérer (installation, mise à jour, maintenance générale).

Un des trucs que j'aime bien dans vim, c'est l'idée de pouvoir faire des phrases pour agir sur le texte. Par exemple, quand le curseur se trouve sur la première lettre d'un mot, dans le mode normal, on peut le remplacer en tapant cw, ce qui signifie littéralement « change le mot » (“change word”). Le problème, avec cette syntaxe, c'est qu'il est impossible de visualiser le bloc de texte qui va être impacté. Dans l'exemple précédent, c'est facile puisque c'est juste un mot, mais quand on commence à travailler sur des lignes ou des paragraphes, ça devient beaucoup plus compliqué.

Il y a quelques années, j'ai entendu parler de Kakoune, une alternative à vim qui fonctionne en inversant l'ordre des actions : on sélectionne d'abord le bloc de texte sur lequel on veut agir, puis on effectue l'action désirée. C'est bien plus agréable à l'usage ! Malheureusement, il s'agit, tout comme vim, d'un éditeur de texte avant tout, donc pour éditer du code, il faut passer pas mal de temps à le configurer.

Puis, l'an dernier, j'ai entendu parler de Helix. Cet éditeur utiliser un paradigme similaire à celui développé par Kakoune pour gérer la sélection de texte, mais il est fourni « avec les piles », ce qui veut dire qu'il n'est pas nécessaire de passer beaucoup de temps à le personnaliser pour pouvoir en profiter en tant qu'éditeur de code.

Une des fonctionnalités les plus intéressantes de Helix pour l'édition de code est le support du Language Server Protocol en natif, ce qui veut dire que, comme VS Code par exemple, il est possible de naviguer dans une base de code assez facilement sans avoir à faire grand'chose à part installer le support du langage de votre choix pour LSP. Dans mon cas, en tant que développeur Python, ça revient à installer le paquet python3-pylsp et l'affaire est dans le sac ! Pour vérifier les fonctionnalités activées dans Helix, on peut lancer hx --health qui affiche un « rapport de santé » avec, entre autres informations, les fonctionalités supportées pour un grand nombre de langages.

Voici quelques commandes que j'utilise souvent dans Helix :

  • Pour sélectionner une ligne, j'appuie sur x. Pour en sélectionner plusieurs, soit je préfixe la commande avec un nombre (3x, comme dans vim), soit j'appuie sur x jusqu'à avoir sélectionné toutes les lignes que je voulais. Il est aussi possible d'utiliser le mode de sélection « visuelle » en appuyant sur v et en déplaçant le curseur.
  • La command gd (“go to definition”) ouvre la définition de la fonction qui se trouve sous le curseur. Cette commande est super utile pour vérifier rapidement ce que fait une fonction. Pour revenir en arrière, on peut utiliser Ctrl+o pour remonter d'un cran (“outside”) dans l'historique de navigation (Ctrl+i permet de naviguer l'historique dans l'autre sens).
  • Pour modifier un terme dans un fichier, j'appuie sur % pour sélectionner l'ensemble du texte, puis s pour lancer une recherche (que je valide avec la touche Entrée). Cela crée des blocs de sélection de toutes les occurrences du terme. Je peux ensuite appuyer sur c pour « changer » ce texte.
  • Pour ouvrir un fichier, j'active le mode Espace (Space mode) en appuyant sur la barre d'espace, puis sur f pour activer le sélecteur de fichiers. Quand on appuie sur la barre d'espace, Helix affiche un petit menu avec les options disponibles, ce qui est très pratique pour les apprendre (et c'est pareil pour le mode de « correspondance » (Matching mode), en placant le curseur sur un mot et en appuyant sur m).
  • Pour trouver toutes les occurences d'un mot dans tous les fichiers d'un dossier, j'utilise la recherche globable en appuyant sur la barre espace, puis sur /. J'utilise très souvent cette recherche pour voir à quels endroits est appelée une fonction donnée, par exemple.
  • Pour commenter ou décommenter une ligne ou un bloc de code sélectionné, j'appuie sur Ctrl+c.

Je recommande chaudement d'essayer le tutoriel (avec la commande hx --tutor) qui permet d'apprendre les bases de Helix ainsi que plein d'autres fonctionnalités plus avancées.

Pour finir, même si la configuration par défaut est très bonne, elle reste fortement paramétrable. Voici quelques modifications que j'utilise au quotidien :

# Un très joli thème qui fonctionne mieux que le thème par défaut avec les
# règles (voir ci-dessous)
theme = "catppuccin_frappe"

[editor]
# Affiche les buffers ouverts s'il y en a plus d'un.
# Cela affiche une ligne, un peu comme une ligne d'onglets, en haut de l'écran
bufferline = "multiple"
text-width = 80
# Affiche une règle verticale à 80 caractères
rulers = [80]
# Je trouve que le panneau qui s'affiche pour aider à compléter est un peu trop
# encombrant, donc je le désactive (on peut afficher les suggestions en
# appuyant sur Ctrl+x)
auto-completion = false

[keys.normal]
# Alt-, and Alt-. pour passer eau buffer précédent/suivant
"A-," = "goto_previous_buffer"
"A-." = "goto_next_buffer"
# Déselectionne la dernière ligne. Très pratique quand on a appuyé un peu trop
# sur x et qu'on a sélectionné trop de lignes...
X = ["extend_line_up", "extend_to_line_bounds"]
# Imite le comportement de vim en allant tout en bas d'un fichier avec la
# touche G
G = "goto_file_end"

[editor.lsp]
# Désactive le popup d'aide qui s'affiche quand on appelle une fonction et qui
# montre la signature de ladite fonction, mais qui prend, je trouve, un peu
# trop de place.
auto-signature-help = false

Je vous conseille vraiment d'essayer cet éditeur. La documentation est très complète, et la communauté est sympa et toujours là pour vous venir en aide, donc n'hésitez pas !

  • # Emacs, une excellent alternative à vim !

    Posté par  (site web personnel) . Évalué à 10 (+18/-2).

    Sinon, y'a emacs.

    Troll Face

  • # Neovim

    Posté par  (Mastodon) . Évalué à 9 (+7/-1).

    J'utilise LSP avec neovim et j'imagine que ce serait pareil avec vim si je n'avais pas fait le switch avant. Donc je ne crois pas que ça fait une grande différence avec Helix.

    Il y a quelques années, j'ai entendu parler de Kakoune, une alternative à vim qui fonctionne en inversant l'ordre des actions : on sélectionne d'abord le bloc de texte sur lequel on veut agir, puis on effectue l'action désirée. C'est bien plus agréable à l'usage !

    En quoi est-ce différent d'utiliser la sélection visuelle de block dans vim/neovim puis d'effectuer l'action sur cette sélection?

    Puis, l'an dernier, j'ai entendu parler de Helix. Cet éditeur utiliser un paradigme similaire à celui développé par Kakoune pour gérer la sélection de texte, mais il est fourni « avec les piles », ce qui veut dire qu'il n'est pas nécessaire de passer beaucoup de temps à le personnaliser pour pouvoir en profiter en tant qu'éditeur de code.

    De la même manière qu'emacs, l'ecosystem neovim a vu l'apparition de "distributions" avec une préconfiguration de plugins courants: LazyVim, LunarVim, AstroVim, NormalVim, Doom-Vim, CyberNvim. J'utilise personnellement LazyVim. C'est un peut pareil, LSP, un gestionnaire de fichiers et une foultitude de plugins sont déjà préinstallés, d'autres comme le support d'un langage juste sélectionnables et autoinstallables à partir d'une liste.

    J'ai toujours Helix installé sur mon PC pro depuis 1 ou 2 ans mais je ne l'utilise pas. J'imagine qu'il est bien mais après plus de 20ans d'utilisation de vim puis de neovim la resistance au changement est trop forte. J'ai les raccourcis claviers et les commandes dans la tête et je n'ai pas vraiment le temps de m'habituer à autre chose. Même MScode/codium est difficile pour moi même avec les plugins qui offrent une compatibilité avec les opérations clavier vim car il y a toujours des différences importantes.

    Dans un sens ça me fait comprendre ce que ressentent les gens qui te disent qu'ils n'arrivent pas à switcher à Linux à cause de Photoshop ou de toute autre appli qu'ils utilisent quotidiennement. Il y a une certaine violence à devoir s'habituer à des raccourci claviers et des flux de travails différents dans un logiciel que tu utilises plusieurs heures par jour.

    • [^] # Re: Neovim

      Posté par  . Évalué à 5 (+3/-0).

      En quoi est-ce différent d'utiliser la sélection visuelle de block dans vim/neovim puis d'effectuer l'action sur cette sélection?

      Quand tu préfère réfléchir ainsi c'est probablement plus agréable que tout le langage soit construit ainsi plutôt que de devoir te cantonner à la seule manière de t'en servir. Si tu veut pouvoir en faire une macro par exemple c'est moins pratique (déjà que je n'arrive pas à faire une macro du premier coup…).

      Dans un sens ça me fait comprendre ce que ressentent les gens qui te disent qu'ils n'arrivent pas à switcher à Linux à cause de Photoshop ou de toute autre appli qu'ils utilisent quotidiennement. Il y a une certaine violence à devoir s'habituer à des raccourci claviers et des flux de travails différents dans un logiciel que tu utilises plusieurs heures par jour.

      Ce n'est pas une violence à moins d'y être contraint, c'est un engagement. Comme tu l'a vécu en apprenant la syntaxe de vi ou de ton shell. Il y a forcément un ticket à l'existant qui est très fort. Les syntaxes de vi et emacs sont partout. Ça ne doit pas empêcher de tenter de proposer autre chose. Je trouverais personnellement extrêmement triste de ne plus voir arriver ce genre de tentatives (et je suis utilisateur de vim et mon shell est configuré pour avoir une syntaxe vimesque).

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Neovim

        Posté par  (Mastodon) . Évalué à 6 (+3/-0).

        Ça ne doit pas empêcher de tenter de proposer autre chose. Je trouverais personnellement extrêmement triste de ne plus voir arriver ce genre de tentatives

        Je ne dénigre pas l'existence de Helix ni sa pertinence. D'autant plus que tout le monde n'est pas déjà formatté à vim.

        Je partage juste l'expérience d'un utilisateur de vim puis de neovim pour que d'autres réalisent l'engagement nécessaire (pour reprendre tes mots).

        Mon expérience c'est ouvrir un fichier avec Helix, et à la première substitution ou autre truc à faire un peu différent de neovim, me dire oups pas le temps, de le fermer, passer à neovim et oublier Helix pendant n mois jusqu'à ce que son existence se rappelle à moi quand je vois passer le nom quelque part ou dans mon package manager lors d'une update. C'est très certainement dommage mais on ne m'a pas non plus démontré ce que je gagnerais à passer à Helix en terme de possibilités.

        • [^] # Re: Neovim

          Posté par  (site web personnel, Mastodon) . Évalué à 5 (+4/-0).

          C'est pour cette raison de « oups pas le temps » que je suis passé à Helix :) J'en avais marre de passer des heures à tester différents plugins, qui cassaient tous quelque chose dans mon installation très instable de vim, puis je voyais passer un article vantant les mérites de la pureté vimesque (moins tu as de plugins, mieux c'est), donc je retentais, mais il me manquait les choses de base que je décris dans mon journal… Bref, c'est pour ça que j'ai bien aimé Helix, de la même façon que j'ai bien aimé Fish parce qu'il a plein de trucs préconfigurés comme il faut, et je n'ai pas besoin d'avoir un fichier de ressource de 50 ko :)

          Tout ça pour dire que je comprends pourquoi tu ne passes pas à Helix : tu as déjà acquis tout ce dont tu avais besoin pour être efficace avec vim, donc tu n'as pas besoin d'aller voir ailleurs !

          • [^] # Re: Neovim

            Posté par  (Mastodon) . Évalué à 6 (+3/-0).

            oui je ne critique pas Helix, j'essaye juste de savoir s'il y a une killer feature qui pourraient motiver un réapprentissage.

  • # Je plussoie

    Posté par  . Évalué à 7 (+6/-1).

    J'ai fait exactement le même cheminement. D'abord vim, puis l'envie de tester quelque chose de différent avec la découverte de kakoune (que j'utilise encore pour son plugin wiki très pratique), puis helix pour quelque chose dans l'esprit de kakoune mais plus "simple".
    Un très bon projet, et assez mature et stable malgré sa jeunesse !

    Un point aussi, il est très simple d'ajouter le support d'un langage non "supporté" de base (j'ai rajouté le support de puppet sur mon installation, ça inclus la compilation du LSP puppet, mise à jour de tout le bouzin avec la commande "hx --grammar build").

    Si tu ne sais pas demande, si tu sais partage !

  • # Vim et selections

    Posté par  . Évalué à 7 (+4/-0).

    Il y a moyen de travailler dans des sélections avec vim. Shift+V l'opérateur de base. Ensuite une commande sera exécutée, de mémoire, dans la sélection.

    https://stackoverflow.com/questions/7406949/vim-faster-way-to-select-blocks-of-text-in-visual-mode Ce post stack overflow donne des astuces pour étendre facilement la sélection par recherche de texte (tu cherches un truc, la sélection est agrandie jusqu'à une des occurrence suivante, au choix)

    • [^] # Re: Vim et selections

      Posté par  (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 30 octobre 2024 à 10:48.

      Oui c'est ce que j'ai aussi mentionné dans mon post, du coup je ne suis pas sûr de saisir la différence.

      • [^] # Re: Vim et selections

        Posté par  . Évalué à 4 (+1/-0).

        Pardon j'avais pas lu attentivement /o\ c'est la même fonctionnalité oui.

        Disons que ce que j'apporte c'est comment faire plus pratique, là ou tu te contentes de donner les mots clés. Peut être que tu supposes que l'auteur du journal n'ignorait pas la fonctionnalité ? Perso je ne l'ai découvert que sur le tard, j'ai pas lu de bouquin exhaustif de vimologie ou quoi.

    • [^] # Re: Vim et selections

      Posté par  . Évalué à 2 (+1/-0).

      Shift+V, c'est le visuel ligne. Pour juste inverser l'ordre des phrases le visual simple suffit : viwc est équivalent à ciw. Le visuel ligne sera pour les opérations par lignes : Vc au lieu de cc (ou Vjc au lieu de c2c). Le visuel bloc (Ctrl+V) est un peu à part et ne correspond pas directement à des commandes simples.

      • [^] # Re: Vim et selections

        Posté par  . Évalué à 3 (+0/-0).

        Tu peux faire des sélections visuelles à la souris aussi, avec 

        :set mouse=a

        avec une résolution plus précise que la ligne, il me semble qu'il y a d'autres moyens d'arriver à ce résultat.

  • # Équivalent non-modal ?

    Posté par  (site web personnel, Mastodon) . Évalué à 5 (+4/-0).

    Merci pour ce journal ! Je réfléchissais justement à en écrire un sur ma quête un peu désespérée d'un éditeur de texte qui me satisfasse.

    J'ai utilisé Emacs plusieurs années, je continue de l'utiliser pour certaines choses et dans l'ensemble j'aime bien, mais je me suis arraché les cheveux avec les n systèmes de paquets différents et la difficulté de configurer un LSP. Le temps perdu m'a un peu refroidi.

    Je suis donc passé à Helix pour la plupart des langages. J'aime beaucoup la configuration simple et lisible en TOML et la facilité d'utilisation des LSP. Le seul hic, c'est que je ne suis pas fan de l'édition modale. Je préfère les raccourcis avec Control, Alt et Control-Alt, et j'aime bien garder les bases des zones de texte de toutes les autres applications que mon éditeur de texte, à savoir : sélection avec Shift, mouvement mot par mot avec Control, et les raccourcis clavier de base Control-X, Control-C, Control-V. (Ça rend la navigation entre plusieurs applications plus fluide pour moi.)

    Est-ce que quelqu'un connaîtrait une sorte d'équivalent de Helix, mais non-modal ?

    (Un autre critère important est que l'éditeur puisse fonctionner dans un terminal, pour les sessions SSH.)

  • # J’aime bien aussi

    Posté par  . Évalué à 1 (+1/-0).

    Salut, je plussoie !!

    Il y a un bon moment maintenant j’ai essayé quelques éditeur de texte modaux, en commençant par kakoune, puis vim et enfin helix et je me suis arrêté là !!

    J’ai beaucoup aimé que "tout soit installé par défaut", les conseils dans l’interface et que la sélection se fasse avant la commande.

    Ceci dit, les EDI me manque vite !

    En ce moment je teste zed qui est très bien ! 

  • # LSP c'est bien, mais avec un debugger, c'est encore mieux !

    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 30 octobre 2024 à 17:27.

    Hello,

    LSP est un protocoleprotocole vraiment pratique pour améliorer l'édition de code, mais il ne permet pas de le debugger.

    Le pendant de LSP pour le debugging est le Debug Adapter Protocol, comme j'en parlais dans mon journal sur la configuration de Vim comme un IDE.

    Est-ce qu'Helix propose le support de DAP pour le debugging également ?

  • # hx

    Posté par  . Évalué à 2 (+0/-0).

    J'utilise Helix comme éditeur principale depuis environ deux ans.
    Pour un peu toutes les raisons déjà évoquées : LSP facile à gérer, nombreuses fonctionnalités out of the box, rapide, en gros un seul binaire à installer, configuration simple à prendre en main.

    Avant j'utilisais CudaText - que j'utilise encore pour certaines manipulations - qui lui même était venu replacer jEdit.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.