Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Décembre 2020 -
Cette année, j’ai découvert l’IDE Visual Studio Code, enfin, son pendant libre VSCodium pour mon travail.
C’est un IDE qui fonctionne plutôt bien, mais je ne me sentais pas très à l’aise avec le fait que l’upstream (Microsoft en l’occurrence) distribue des binaires sous licence non open-source et ajoute de la télémétrie par défaut. En plus, c’est développé avec Electron et, bien que j’aime beaucoup utiliser nodejs, je trouve vraiment lourd d’avoir un Chrome complet lancé juste pour mon IDE.
D’un autre côté, j’aimais bien utiliser vim comme éditeur de configuration et de petits textes sur mon serveur.
J’avais tenté plusieurs fois de configurer vim comme IDE, mais j’ai eu pas mal de peine à comprendre comment ajouter et activer des plugins.
En fait, si on regarde le site vimawsome, on voit déjà listé 4 gestionnaires de plugins différents pour vim.
J’étais un peu perdu aussi par Debian qui empaquette des plugins et propose en dépendance vim-addon-manager pour activer les plugins installés.
Bref, j’ai essayé plusieurs fois de configurer vim et je n’ai pas réussi.
Cette année, j’ai appris que, depuis la version 8 de vim, il y a un gestionnaire de paquet officiellement supporté et activé par vim !
En plus, il permet d’activer les plugins très simplement:
1. Créer un “pack” où l’on va installer nos plugins : mkdir – p ~/.vim/pack/adrien/{start, opt}
(les plugins dans start sont actifs dès le démarrage de vim, ceux dans opt s’activent avec la commande : packadd)
2. Installer un plugin dans ce répertoire, par exemple pour ctrl-p (la recherche de fichiers):
cd ~/.vim/pack/adrien/start;
git clone https://github.com/kien/ctrlp.vim
Bon, une recherche aisée dans les fichiers, c’est un bon début pour un IDE, mais ça n’est clairement pas suffisant.
Un des gros apports de Visual Studio Code est son système Language Server Protocol (LSP) qui permet de partager entre les différents IDE l’analyse syntaxique et les aides au développement pour chaque langage de programmation. En théorie, c’est beau, mais je ne l’avais pas encore vraiment vu appliqué.
Eh bien, j’ai découvert que le plugin coc.nvim permet de faire le lien entre vim et les différents LSP développés pour Visual Studio Code (en général, sous licence MIT par Microsoft). Le truc, c’est que, les LSP développés pour Visual Studio Code sont développés sous forme d’extensions indépendantes de Visual Studio Code et, du coup, coc.nvim propose de faire l’interface entre vim et les extensions utilisées par Visual Studio Code.
Oui, vous avez bien suivi, j’ai commencé par dire que j’étais perdu avec les multiples gestionnaires d’extensions de vim et, là, je viens de proposer un plugin qui installe ses propres extensions avec son propre gestionnaire. C’est une belle mise en abyme que j’aurais préféré éviter, mais qui fonctionne bien, ma foi !
Il est à noter également, que le plugin coc.nvim dépend de nodejs et npm, ça ajoute donc quand même pas mal de dépendances à un « simple vim ».
Mais comme je travaille déjà avec ces technologies, ça ne m’a pas posé plus de problèmes que ça.
Bien, maintenant, j’ai un vim capable de chercher rapidement des fichiers dans le dossier courant et de m’aider à programmer selon les types de fichiers.
C’est déjà bien, mais il me manque encore un outil très important : le débugueur pour inspecter ce qui se passe dans mon code facilement.
J’ai travaillé un temps avec Visual Studio Code ouvert presque uniquement pour l’outil de debug, mais ce n’était pas vraiment pratique.
À force de chercher un moyen de debug du nodejs dans vimawsome, je comprends enfin que je peux utiliser l’excellent Vimspector (même si ce n’est pas bien indiqué dans le README, il supporte node ≥12 avec l’adaptateur vscode-node-debug2).
Grâce au fichier README de Vimspector, j’apprends que Visual Studio Code a aussi développé un protocol pour les débugueurs nommés Debug Adapter Protocol(DAP) dans la même veine que LSP, mais dédié au debug des langages.
Du coup, j’ajoute encore un système de plugin dans mon IDE (en plus de celui de vim et de coc.nvim), mais à nouveau, ça marche bien et ça me permet de me familiariser avec une seule interface de debug pour plusieurs langages de programmation.
Il faut savoir que pour pouvoir utiliser Vimspector, il faut avoir une version de vim très récente (version au moins 8.2), compilé avec le support de python 3.6 au moins.
Finalement, j’ajoute encore quelques pugins à vim pour afficher de belles couleurs (oceanic-next) et utiliser les fichiers .editorconfig (editorconfig-vim) et j’ai un IDE qui me plaît beaucoup et qui me semble reste léger malgré tous ces ajouts.
Depuis que j’utilise vim plus intensément, j’ai découvert ces fonctionnalités vraiment sympa:
- la commande
:term (ou :terminal) pour faire un split du buffer actuel et afficher un buffer avec un terminal. C’est très pratique pour rester avec la session vim ouverte avec tous les fichiers en cours de modification et pouvoir lancer quelques commandes git, meson ou ninja.
- les popups (nommés popovers dans GTK) d’aide que coc.nvim peut afficher directement sous la ligne active si vim est assez récent
- les raccourcis claviers très pratique comme
gd (go to definition), "+y (pour copier depuis vim vers le presse-papier graphique)…
- la commande
:ls pour lister les fichiers ouverts et :b 1 pour afficher dans le buffer courant un des fichiers ouverts
- les onglets. En fait, les buffers et split des windows sont déjà très pratiques, mais les onglets sont aussi pratiques pour avoir plusieurs espaces de travail simultanés.
Vimspector en fait un très bon usage : dès qu’une session de debug est démarrée, Vimspector ouvre un nouvel onglet avec plusieurs buffers organisés pour le debug.
- la commande
:Lexplore pour ouvrir une barre d’exploration sur la gauche et la configuration de netrw pour naviguer dans l’arborescence
- le fait qu’un vim local peut modifier des fichiers à distance grâce à SSH et
netrw
Enfin, comme j’ai commencé à utiliser aussi vim pour mes projets persos, j’ai préparé un répertoire git avec mes fichiers de configuration si vous voulez tous les détails.
Commentaires :
voir le flux Atom
ouvrir dans le navigateur
