Licence CC BY

Emacs, montre moi ces espaces que je ne saurais voir

Comment j’ai galéré pour configurer Emacs sur un point ultra-particulier

Je suis du genre psychorigide. Quand j’utilise un logiciel, j’aime avoir la possibilité de le personnaliser. Je ne le fais pas toujours, parce que mine de rien, ça peut facilement prendre un temps fou — c’est d’ailleurs le sujet de ce billet — et c’est potentiellement très frustrant quand on n’arrive pas à ses fins.

J’ai passé des années à utiliser vim, que l’on ne présente plus. Pendant tout ce temps, j’ai eu plus que l’occasion de me construire un vimrc sur mesure. J’ai pu essayer beaucoup de choses, pour finalement me forger un environnement de travail dans lequel je suis à l’aise. Le fonctionnement modal de vim, ses raccourcis clavier, un thème très minimaliste sans coloration syntaxique ou presque, etc. Il y a un peu plus d’un an, j’ai « malheureusement » dû me résoudre à utiliser emacs, que l’on ne présente plus non plus. Les gens derrière coquille ont décidé de ne pas porter leur plug-in pour qu’il fonctionne avec les dernières versions de Coq et je fais beaucoup de Coq dans le cadre de ma thèse.

J’ai donc naturellement essayé de me reconstruire un environnement de travail, sinon identique, au moins le plus proche possible de ce que je devais plus ou moins quitter. Ça s’est fait par à-coup, mais j’ai finalement réussi à converger vers quelque chose de satisfaisant ! Ceux que ça intéresse peuvent retrouver sur mon site mon fichier de configuration complet. Il faut encore que je refasse une passe sur l’anglais avant de le diffuser plus largement, mais j’ai essayé de donner pas mal de détails sur le pourquoi du comment de chaque morceau de configuration.

Mon thème emacs personnalisé aux petits oignons

Ce billet est là pour décrire les difficultés que j’ai pu rencontrer pour… afficher avec des caractères particuliers les espaces, tabulations et retours à la ligne. Quelque chose qui se fait très simplement avec vim, d’une manière ô combien satisfaisante :

1
set list listchars=tab:>\ ,space:·,eol:$

whitespace-mode, mon amour

Le package idiomatique pour jouer avec l’affichage des espaces dans emacs est whitespace.el, qui est normalement livré avec l’éditeur (en tout cas dans toutes les versions que j’ai pu tester). Une fois le plug-in correctement chargé (en utilisant require, ou une autre solution comme use-package), il est assez facile à utiliser.

D’abord, je l’active tout le temps, parce que j’en viens à être mal à l’aise quand je ne vois pas mes petits · partout dans mon document.

1
(global-whitespace-mode t)

La seconde étape est de le configurer. Normalement, le package possède tout ce qu’il faut pour faire ce que je désire faire : il est possible (1) d’afficher un autre caractère à la place des espaces, tabulations, etc., et (2) de lui assigner un style particulier.

Le souci, c’est que ce style s’impose sans se soucier du contexte, ce qui fait que le rendu peut être pour le moins… disgracieux.

Bien essayé, mais peut mieux faire…

J’ai beaucoup cherché, pour finalement tomber sur un thread StackOverflow1 posant peu ou prou une question similaire à mon problème. La réponse était sans appel : ce n’est pas possible, en tout cas pas sans changer whitespace.el. N’ayant pas spécialement envie de porter cette croix moi-même, je me suis mis en quête d’une solution palliative. En attendant, on peut tout de même utiliser whitespace-mode pour afficher les fameux caractères comme on le souhaite, parce que ça, il le fait très bien :

1
2
3
4
5
6
7
8
(setq whitespace-style '(tab-mark newline-mark space-mark))
  (setq whitespace-display-mappings
        '((tab-mark 9 [9655 9] [92 9])
          (newline-mark 10 [182 10])
          (space-mark 32 [?·] [46])
          (space-mark ?\xA0 [?~] [46])
          )
        )

  1. Que je ne retrouve plus aujourd’hui, désolé. ): 

highlight-chars, mon sauveur

Il se trouve que l’Emacs Wiki possède une page sur cette thématique de la visualisation des espaces et que cette dernière mentionne un autre package en plus de whitespace.el: highlight-chars.el.

Ce package permet d’assigner un style particulier à des caractères de manière assez fine… et possède les options nécessaires pour « fusionner » ce style avec l’existant ! C’est exactement ce que je voulais : victoire !

À configurer, c’est un bonheur. Après l’avoir chargé correctement, je n’ai qu’à ajouter cette ligne à ma configuration :

1
(hc-highlight-chars '(" " "\t" "\n") 'whitespace-space)

Autrement dit, j’assigne aux caractères qui m’intéressent la face définie par whitespace.el. Comme ce n’est pas ce dernier, mais bien highlight-chars qui l’assigne, les caractéristiques de whitespace-space sont fusionnées avec celle de la face courante.

linum, mon nemesis

Je pensais être tiré d’affaire, à ma grande satisfaction, mais c’était sans compter les importants ralentissements qui ont commencé à se manifester quand un document possédait des lignes avec beaucoup d’espaces.

C’en est suivi une longue phase d’essais et d’échecs pour trouver une solution acceptable, parce qu’il était inconcevable que emacs tousse chaque fois que je faisais défiler un fichier un peu ordonné. Il se trouve qu’en désactivant le linum-mode (qui permet d’afficher les numéros de ligne dans un buffer), tout allait beaucoup mieux.

C’est fou, non ?

Dans l’absolu, je ne me sers pas énormément de ces fichus numéros de ligne, alors j’aurais pu m’en passer. Je pense. Mais, et c’est d’ailleurs la première phrase de ce billet, je suis un peu psychorigide et ça m’embêtait beaucoup de céder à un « caprice » du logiciel que j’utilise. Qui plus est, ce n’est pas du tout satisfaisant. Emacs reste un logiciel fonctionnel qui devrait être capable d’afficher en même temps les numéros de ligne et les espaces. D’ailleurs, il en est capable, car quand c’est whitespace.el qui se charge du style, tout va pour le mieux. Dommage qu’il ne puisse pas le faire correctement.

En fouillant un peu, j’ai trouvé une solution : nlinium. Présenté peu ou prou comme le futur de linum.

Avec nlinum, tout va pour le mieux !

Du coup, mission accomplie. Ça a été difficile, j’ai passé un nombre d’heures assez hallucinant pour finalement une solution qui tient en quelques lignes… mais j’ai l’impression que ce besoin n’est pas spécialement partagé dans la communauté Emacs.

Applique ton style

Il reste une dernière chose à dire pour qu’un lecteur intéressé puisse reproduire l’expérience complètement : personnaliser un thème donné pour choisir la couleur des espaces. C’est utile, parce que les emacseux ont plutôt l’air dans le délire d’afficher de manière bien visible les espaces, avec des fonds différents par exemple.

1
2
3
4
(custom-theme-set-faces
  '<ton thème>
  '(whitespace-space ((t (:foreground "<ta couleur>"))))
  )

Tout mit bout à bout, il n’y a pas tant de lignes de configuration que ça… mais on est tout de même loin de la concision permise par vim. Je trouve surtout dommage de dépendre de trois packages pour avoir une solution efficace et fonctionnelle. Du coup, si quelqu’un connaît une manière plus simple de faire, ça m’intéresse grandement.

8 commentaires

J’ai réalisé la semaine dernière que ProofGeneral ne supportait plus Isabelle et qu’il faut se restreindre à utiliser jEdit, un éditeur graphique fournit par défaut avec Isabelle et c’est vraiment pénible de devoir changer d’éditeur.

Après sur le texte que tu présentes, je ne vois pas trop ce que tu cherches à corriger entre l’image de l’article et celle au début. Ce qui est disagracieux c’est peut-être le background qui change, mais est-ce qu’il n’y a que cela ?

Sinon je suis allé jeter un coup d’oeil à ta configuration. Je ne connais pas bien le evil-mode, mais j’ai l’impression que spacemacs commence à s’imposer sérieusement pour ceux qui aiment bien vim.

Sinon pour OCaml, je te conseille d’utiliser Merlin (via OPAM), c’est vraiment pratique (et ocp-indent qui est meilleur que tuareg je trouve).

+0 -0

Ce qui est disagracieux c’est peut-être le background qui change, mais est-ce qu’il n’y a que cela ?

Effectivement, il n’y avait que cela, mais ça suffisait à me gratter le cerveau 8).

J’avais regardé spacemacs rapidement ; il faudra que je m’y penche plus, mais disons que j’ai un mapping un peu spécifique des touches hjkl et je n’ai jamais pris le temps de voir si c’était facile de modifier spacemacs pour l’utiliser. J’imagine.

Je note pour OCaml ; pour l’heure, je n’en fais pas, mais comme j’envisage de travailler avec du code extrait de Coq vers Ocaml, ça me sera très certainement utile.

+0 -0

Ahah. Je me demandais si la question allait venir.

À une époque, j’étais tombé sur plusieurs articles qui expliquaient pourquoi c’était une bonne idée de « désactiver la coloration syntaxique », mais je ne les retrouve plus.

Globalement, ce que j’en ai retenu c’était qu’il était possible (je ne sais plus si les articles en question utilisaient le conditionnel ou non) que la coloration syntaxique gène à la lecture du code. Je crois que l’argument avancé était que « reconnaître une couleur » demande du temps de cerveau finalement pas si négligeable et que ça poussait à reconnaître les motifs plutôt que de lire linéairement.

Il se trouve que maintenante, ça va faire je pense plus d’un an que je suis passé à un thème minimaliste ou globalement je ne colore que les chaines de caractères (pour voir quand j’ai oublié de les fermer) et les commentaires (ça me permet aussi de structurer mon code source, notamment avec la doc). Je remarque que je suis effectivement gêné par la coloration syntaxique (1) en règle générale et (2) quand elle se trompe (ce qui n’arrive pas quand elle est absente d:).

Je n’irai pas jusqu’à conseiller à quiconque de faire de même, mais je sais que personnellement, je vis mieux sans désormais !

+1 -0

Salut,

Je suis agréablement supris de lire un avis similaire au miens en ce qui concerne la coloration syntaxique : les sapins de noël, c’est pour décorer, par pour coder. :p

Bon après je n’en utilise pour ma part pas du tout, mais c’est plus par flemme de configuration qu’autre chose. :-°

+0 -0

J’aime beaucoup la coloration syntaxique, mais il faut que les couleurs soient ternes, le côté flashy me gêne assez rapidement. Très souvent, elle permet de donner une lecture rapide du code que l’indentation ne permet pas toujours (en OCaml de mon côté).

Très souvent, elle permet de donner une lecture rapide du code que l’indentation ne permet pas toujours (en OCaml de mon côté).

L’un des arguments qui revient aussi en faveur de la coloration syntaxique, c’est que ça pousse effectivement a bien organiser son code, pour qu’il soit plus lisible sans artifice.

Bon après je n’en utilise pour ma part pas du tout, mais c’est plus par flemme de configuration qu’autre chose. :-°

Ahah, ravi de rencontrer un autre converti ! Après, personnellement, je préfère quand même il y a un minimun de coloration pour les commentaires et les chaînes de caractères.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte