Ajoutez la coloration syntaxique à nano et vi(m)

Cet article a été publié il y a 9 ans 5 mois 29 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

J’ai beau utiliser Sublime Text 2 (avec quelques rajouts), il existe un petit village d’irréductibles qui ne jurent que par des outils en ligne de commande pour le développement. Enfin pas seulement, d’ailleurs n’importe quel administrateur système Linux vous dira que des outils comme nano et vi(m) (ou emacs pour les extraterrestres) font partie du kit de survie standard. Un poil de personnalisation ne fait donc pas de mal, et bizarrement, si l’on aime dire que vi(m) est plus compliqué que nano, on va vite être surpris (enfin presque).

Nano

Nano est fourni avec plusieurs « profils » qui peuvent s’activer en fonction de l’extension du fichier (ou son type, mais on sait que c’est pas toujours la même chose). Seulement, il se peut que par défaut ces profils de coloration ne soient pas activés. On pourra utiliser deux approches, l’une globale et l’autre spécifique à un utilisateur. Regardons la méthode globale, qui dans le cas de la coloration syntaxique, me semble tout de même plus logique et n’influe pas sur la sécurité. On va se concentrer sur la fin du fichier de configuration /etc/nanorc :

Je n’affiche pas tout, ça serait trop gros, et de toute façon inutile. On a donc une série de fichiers *.nanorc qui sont appelés par la directive include. Enfin là, ils sont commentés, donc pour ajouter le PHP, on enlèvera le # devant la ligne include « /usr/share/nano/php.nanorc ». La prochaine fois que vous demanderez à nano de vous ouvrir un fichier php, le code sera un peu plus lisible grâce aux couleurs. Libre à vous de décommenter les syntaxes qui vous intéressent. Les plus bourrins pourront aussi créer/modifier la leur.

Fait étonnant, Debian semble les activer par défaut, alors que ce n’est pas le cas sur ma Manjaro, et pas plus sur CentOS 7. On peut donc soit modifier le fichier global, soit les ajouter/modifier dans un fichier ~/.nanorc qui donc doit se trouver à la racine de votre dossier personnel. C’est d’ailleurs ce que je conseille de faire pour d’autres réglages qu’on pourrait appliquer à nano, notamment l’indentation automatique, l’affichage des numéros de lignes, le retour auto à la ligne, qui permettent de transformer nano en véritable éditeur de code (il ne lui manquerait presque que l’auto-complétion). Je vous laisse sur la page de man pour découvrir les possibilités.

vi(m)

C’est aussi la méthode locale que je conseillerais pour vi. Mais vous remarquerez que j’écris un (m) entre parenthèse. En effet, Sous Debian, ce n’est pas vi pur qui est utilisé, mais vim, pour Vi IMproved, qui est une extension de vi. Pour l’installer sur Manjaro et CentOS, et surtout l’utiliser par défaut, il faut un peu plus de manipulations. L’installation tout d’abord :

Ensuite, si vous avez lu l’article sur la personnalisation de bash, vous aurez compris où je voulais en venir avec « l’utiliser par défaut ». On va donc créer un alias dans notre fichier .bashrc (ou global, ce qui aurait plus de sens ici) :

Les alias étant prioritaires sur les scripts/liens dans /usr/bin & compagnie (les chemins inclus dans PATH quoi), c’est donc vim qui sera appelé à l’avenir à la place de vi.

Passons donc maintenant à la configuration. C’est là qu’on va se rendre compte que c’est plus simple que nano. En effet, s’il n’existe pas encore on va créer un fichier .vimrc à la racine de notre dossier utilisateur (/home/seboss666 pour moi), et y inclure les deux directives suivantes :

Et voilà, c’est aussi simple que ça. Il est d’ailleurs possible des les utiliser « à la volée », directement dans vim, en les précédant d’un « : » (qui indique à vim qu’on va lui faire exécuter une commande).

Conclusion

Comme je l’ai dit en introduction, la plupart du temps vous manipulerez vos lignes de codes dans des éditeurs graphiques (que ce soit Sublime Text, Kate, Gedit, Leafpad, Notepad++ et j’en passe). Mais de temps en temps, pour dépanner, ou quand on a pas le choix (serveur sans interface graphique), avoir un éditeur en ligne de commande qui en fasse un peu plus ne fait jamais de mal. Et la coloration syntaxique peut vite devenir un vrai plus, notamment pour détecter des erreurs d’écriture. Pensez-y.