Delta : visionneuse paginée avec coloration syntaxique pour les sorties Git, diff, grep et blame

(github.com/dandavison)

3 points par GN⁺ 2024-11-09 | 1 commentaires | Partager sur WhatsApp

Delta est une visionneuse paginée avec coloration syntaxique pour les sorties Git, diff et grep, conçue pour rendre la lecture des diff plus efficace et plus agréable
Dans la plupart des gestionnaires de paquets, le paquet s’appelle git-delta, mais l’exécutable est delta, et il peut être utilisé comme pager Git via core.pager = delta dans ~/.gitconfig
Parmi ses fonctions principales : les mêmes thèmes de coloration syntaxique que bat, la mise en évidence des diff mot par mot basée sur l’algorithme d’inférence d’édition de Levenshtein, la vue côte à côte, les numéros de ligne, la navigation avec n/N et un affichage amélioré des conflits de fusion
Les sorties de git blame, rg, git grep et grep sont elles aussi colorées syntaxiquement, et --hyperlinks permet de transformer les hachages de commit en liens vers des hébergeurs comme GitHub, GitLab, SourceHut ou Codeberg
Il peut rester très proche de la sortie Git/diff par défaut ou modifier largement la disposition et le style, afin d’ajuster finement l’environnement de revue de diff dans le terminal

Ce que fait Delta

Delta est une visionneuse paginée avec coloration syntaxique pour les sorties Git, diff et grep
Son objectif est de rendre le temps passé à lire les diff plus efficace et plus agréable dans un environnement où le code change en permanence
Il permet de modifier largement la mise en page et le style des diff, tout en pouvant rester très proche de la sortie Git/diff par défaut si on le souhaite

Installation et configuration de base

La documentation d’installation est disponible sur Install it
Dans la plupart des gestionnaires de paquets, le nom du paquet est git-delta et celui de l’exécutable est delta
Ajoutez la configuration suivante à ~/.gitconfig pour l’utiliser comme pager Git et filtre de diff interactif

[core]
    pager = delta

[interactive]
    diffFilter = delta --color-only

[delta]
    navigate = true  # use n and N to move between diff sections
    dark = true      # or light = true, or omit for auto-detection

[merge]
    conflictStyle = zdiff3

La même configuration peut aussi être appliquée avec les commandes git config --global

git config --global core.pager delta
git config --global interactive.diffFilter 'delta --color-only'
git config --global delta.navigate true
git config --global delta.dark true  # or `delta.light true`, or omit for auto-detection
git config --global merge.conflictStyle zdiff3

L’aide est disponible via delta -h, le manuel complet via delta --help, et la documentation en ligne dans le user manual

Fonctions de lecture des diff

La coloration syntaxique utilise les mêmes thèmes que bat
La mise en évidence des diff mot par mot repose sur l’algorithme d’inférence d’édition de Levenshtein
La vue côte à côte et le retour à la ligne sont pris en charge
L’affichage des numéros de ligne est pris en charge
Il est possible de naviguer entre les fichiers d’un gros diff, ou entre les diff dans l’affichage de log -p, avec les touches n et N
- Cette fonction s’active avec --navigate
Les sorties unified diff traditionnelles sont également prises en charge avec la sortie Git
La détection automatique des fonds de terminal clairs/sombres est possible

Modes d’affichage et thèmes

Tous les thèmes de coloration syntaxique fournis par bat peuvent aussi être utilisés dans Delta
- delta --show-syntax-themes --dark
- delta --show-syntax-themes --light
La vue côte à côte est documentée dans Side-by-side view user manual

[delta]
    side-by-side = true

Dans la vue côte à côte, les numéros de ligne sont activés par défaut et la coloration syntaxique est appliquée aux panneaux de gauche comme de droite
La vue côte à côte replie automatiquement les lignes longues
La fonction de numéros de ligne est documentée dans Line numbers user manual

[delta]
    line-numbers = true

Prise en charge selon les opérations Git

L’affichage des conflits de fusion est proposé dans un format amélioré, avec une documentation associée dans Merge conflicts user manual
La sortie de git blame prend en charge la coloration syntaxique, et avec --hyperlinks, les commits peuvent être transformés en liens vers l’hébergeur
- Hébergeurs pris en charge : GitHub, GitLab, SourceHut, Codeberg
- Documentation associée : Git blame user manual
Les sorties de grep comme rg, git grep et grep bénéficient aussi de la coloration syntaxique
- Documentation associée : Grep user manual
La fonctionnalité --color-moved de Git est prise en charge

Style et modes de compatibilité

Le code peut être copié directement depuis le diff, et les marqueurs -/+ sont supprimés par défaut
Des modes d’émulation diff-highlight et diff-so-fancy sont proposés
Les hachages de commit peuvent être reliés aux pages des hébergeurs via le format de hyperlinks du terminal
Les chemins de fichier peuvent aussi être transformés en liens hypertexte ouvrables par le système d’exploitation
Les encadrements/lignes décoratives qui mettent en valeur les sections d’en-tête de commit, fichier et hunk peuvent être stylisés
Des chaînes de style sont prises en charge pour plus de 20 éléments de style, avec couleur de premier plan, couleur d’arrière-plan et attributs de police
- Le langage de style utilise le même langage de couleur/style que Git

1 commentaires

GN⁺ 2024-11-09

Avis sur Hacker News

Delta est un outil qu’on configure une fois puis qu’on oublie, et cela fait un moment que je n’ai pas vu la sortie « brute » de git grep/diff/blame
Je l’utilise aussi toujours pour les diffs ordinaires hors d’un dépôt Git, et j’ai découvert aujourd’hui qu’on pouvait aussi l’utiliser avec ripgrep
https://dandavison.github.io/delta/grep.html
bat, déjà mentionné, est lui aussi un outil qu’on configure une fois puis qu’on oublie : j’ai donc défini cat comme alias de bat, et gardé le « cat d’origine », /usr/bin/cat, séparément sous l’alias vcat
https://github.com/sharkdp/bat
- Pour empêcher l’expansion de l’alias, il suffit d’utiliser \cat
Je garde en tête une bonne remarque lue il y a quelque temps : la coloration syntaxique actuelle met en évidence les mauvaises choses
Les humains distinguent bien la syntaxe, donc ce n’est pas la syntaxe qu’il faut colorer, mais les symboles. Attribuer une couleur différente à chaque nom de variable et de fonction distinct correspond mieux à l’objectif : non pas dire « ceci est un symbole », mais « distinguer plus vite des symboles différents »
Cela dit, c’est beaucoup plus difficile que d’orner la syntaxe, si bien que les outils semblent rester du côté le plus facile plutôt que le plus utile. La coloration syntaxique aide déjà pas mal, mais j’aimerais voir si un moteur de correspondance de symboles fonctionne vraiment bien en pratique
Je ne me souviens plus où j’ai lu le texte original, donc je ne peux pas vraiment le citer correctement
En cherchant, je suis tombé sur cet article : https://www.wilfred.me.uk/blog/2014/09/27/the-definitive-gui...
- Dans KDevelop, ils appelaient cela non pas de la coloration syntaxique, mais de la coloration sémantique
  Il me semble que cela existait encore plus tôt, mais le plus ancien billet explicatif que je trouve date de 2009 : https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from...
- L’auteur de cet article a aussi créé difftastic, un « diff structurel qui comprend la syntaxe » en utilisant treesitter
  https://difftastic.wilfred.me.uk/
  https://github.com/Wilfred/difftastic
- Je suis entièrement d’accord. Au début, cela m’a paru étrange, mais une fois habitué, j’ai fini par préférer ce type de coloration
  Personnellement, j’utilise color-identifiers-mode dans Emacs
  https://github.com/ankurdave/color-identifiers-mode
- On arrive aussi assez bien à distinguer les noms de variables. Surtout quand la syntaxe elle-même est mise en évidence, on sait exactement où regarder et ce qu’on peut ignorer
  Je ne suis pas totalement convaincu par cet argument, mais cela m’intrigue un peu
  Il m’arrive de surligner manuellement une variable pour la suivre et vérifier que je n’ai manqué aucune utilisation ; pour cet usage, je comprends très bien l’intérêt. En revanche, je ne sais pas s’il y a assez de couleurs et de contraste pour suivre plusieurs variables en même temps, et l’écran peut aussi devenir fouillis
  Un compromis pourrait consister à ne colorer manuellement que trois variables environ au maximum. Cela dit, si l’on a besoin d’une telle aide, c’est peut-être déjà le signe que le code est peu lisible. Bien sûr, aider à travailler dans une base de code brouillonne reste un usage légitime
Ce n’est pas spectaculaire, mais si l’on veut un diff au niveau des mots à peu près correct avec le seul git standard, ceci suffit souvent
git diff --color-words --word-diff-regex='\w+|.'
- Comment l’activer par défaut dans .gitconfig ?
Delta fait très bien son travail, mais je me suis constamment heurté au problème des longues lignes tronquées
En voyant cet article, j’ai vérifié si la situation avait changé, et c’est effectivement le cas. Désormais, si l’on définit git config --global --replace-all delta.max-line-length 0, les lignes ne sont plus coupées
Je ne sais pas très bien pourquoi ce n’est pas la valeur par défaut. La discussion sur le changement est ici : https://github.com/dandavison/delta/pull/290
- La raison pour laquelle ce n’est pas la valeur par défaut est expliquée telle quelle dans cette PR
  La coloration syntaxique de très longues lignes, par exemple dans des fichiers .js minifiés, peut devenir très lente si elles ne sont pas tronquées
Puisqu’on parle de diff, ce qui m’agace dans la sortie diff de Git, c’est qu’elle affiche les chemins de fichiers comme un diff Unix traditionnel, en commençant par deux noms de fichiers
--- a/some/path/to/file.c
+++ b/some/path/to/file.c
Dans iTerm, j’utilise souvent cmd-clic pour ouvrir un fichier dans l’éditeur, mais ici cela ne fonctionne pas à cause des préfixes a/ et b/. Existe-t-il un moyen de faire en sorte que Git formate mieux les noms de fichiers ? Les deux lignes ne sont même pas vraiment nécessaires
- git config --global diff.noprefix true
  Pour les autres options liées aux préfixes, voir le manuel
J’utilise delta et difftastic ensemble, et les deux sont excellents
difftastic est notamment très fort sur la syntaxe AST de tree-sitter ; c’est un peu lent, mais un diff qui connaît l’AST est vraiment appréciable
Delta est propre et très rapide
Une astuce utile pour activer ou désactiver la fonction side-by-side de Delta selon la taille de la fenêtre. Ici, c’est pour bash ; pour les autres shells, à adapter soi-même
function delta_sidebyside {
if [[ COLUMNS -ge 120 ]]; then
DELTA_FEATURES='side-by-side'
else
DELTA_FEATURES=''
fi
}
trap delta_sidebyside WINCH
- Il manque un $ devant COLUMNS, et il faudra probablement aussi faire un export avant de définir DELTA_FEATURES
J’utilise à la fois delta et difftastic, et je ne les recommanderai jamais assez
Si vous utilisez ne serait-ce qu’un peu le terminal, vous devriez les installer
- Difftastic et Delta ne fonctionnent pas uniquement dans un terminal pur
  Les deux sont pris en charge dans Magit d’Emacs, ainsi que dans Lazygit
- J’utilise difftastic depuis un moment, et je me demande comment on fait pour utiliser les deux ensemble
tig mérite aussi qu’on y jette un œil : https://jonas.github.io/tig/
Comme j’utilise déjà un git diff ordinaire avec des couleurs, j’aimerais aimer celui-ci, mais il a l’air beaucoup trop complexe
- diffr pourrait vous plaire : https://github.com/mookid/diffr
  Pour info, c’est mon projet
- J’ai eu la même impression. Je n’ai jamais vraiment eu l’impression que le git diff d’origine posait problème

Delta : visionneuse paginée avec coloration syntaxique pour les sorties Git, diff, grep et blame

Ce que fait Delta

Installation et configuration de base

Fonctions de lecture des diff

Modes d’affichage et thèmes

Prise en charge selon les opérations Git

Style et modes de compatibilité

À lire aussi

1 commentaires

Avis sur Hacker News