La revue

Chaque opération est une action nommée : un élément de menu avec son équivalent clavier natif de macOS, réassignable via la table keys de la configuration. La souris fonctionne partout, mais rien ne l'exige. La barre d'outils de la fenêtre porte les actions courantes pour les jours à la souris, et ⇧⌘H revient à l'écran d'accueil ; les feuilles se confirment avec ⌘↩ (Retour tape un saut de ligne dans le corps).

Par défaut	Action
⌘↓ / ⌘↑	changement suivant / précédent
⌥⌘↓ / ⌥⌘↑	hunk suivant / précédent
⇧⌘↓ / ⇧⌘↑	fichier suivant / précédent
⇧⌥⌘↓ / ⇧⌥⌘↑	fichier non relu suivant / précédent
⌥⌘V	marquer le fichier courant comme relu ↔ le démarquer
⌘F	rechercher dans le diff (la barre de recherche native)
⌥⌘T	vue unifiée ↔ scindée
⌥⌘C	contexte complet : le fichier entier avec les hunks superposés
⌥⌘←	plier / déplier le hunk courant
⇧⌥⌘← / ⇧⌥⌘→	plier / déplier tous les hunks
⌥⌘S	cycler la coloration : syntaxe + teintes → teintes seules → brut
⌥⌘W	replier les lignes longues
⌃⌘S	afficher ou masquer la barre des fichiers

La coloration syntaxique lance une passe tree-sitter par côté et par hunk : les constructions multilignes se colorent correctement des deux côtés d'un changement. Quatorze langages sont intégrés.

En vue scindée, les deux côtés occupent des panneaux parallèles ; le panneau où se trouve le curseur décide du côté que vise un commentaire.

Fichiers relus

⌥⌘V marque comme relu le fichier à l'écran ; la barre latérale met une coche devant, atténue son nom et compte la progression en haut — « 3 sur 12 relus ». Un clic sur la coche fait de même. ⇧⌥⌘↓ va au fichier non relu suivant, en revenant au début après la fin de la liste, et ⇧⌥⌘↑ au précédent ; quand tous sont marqués, il le dit.

Une marque appartient aux changements sur lesquels elle a été posée. Si le diff d'un fichier change — un nouveau push, un arbre de travail modifié — la marque tombe et le fichier compte de nouveau comme non relu, comme le « Viewed » de GitHub. Un rebase qui ne fait que décaler les numéros de ligne garde la marque.

Les marques ne regardent que vous : elles sont enregistrées avec vos brouillons et jamais envoyées à la forge. Un document d'échange ne les porte pas non plus. Le shell Linux n'a pas encore les marques.

Un commit à la fois

La fenêtre d'une pull request porte un sélecteur de commits au début de sa barre d'outils : All changes, puis chaque commit de la demande, du plus ancien au plus récent, sous la forme abc1234 titre. Choisir un commit remplace la revue, dans la même fenêtre, par les changements de ce commit par rapport à son parent ; choisir All changes revient en arrière. Le titre affiche owner/repo#N @ abc1234 tant que vous êtes sur un commit. (Sur macOS pour l'instant ; le shell Linux n'a pas encore le sélecteur.)

Par défaut	Action
⌃⌘C	revoir un commit : la même liste en menu, flèches et Retour
⌃⌘↓ / ⌃⌘↑	commit suivant / précédent (All changes vient en premier)

Chaque commit est une revue à part entière. Ses brouillons sont gardés à l'écart de ceux de la demande entière et de ceux des autres commits, et reviennent quand vous choisissez de nouveau ce commit ; le sélecteur compte les brouillons qui attendent sur chacun.

Les commentaires écrits sur un commit sont soumis à la pull request épinglés à ce commit, comme les publie la vue d'un seul commit de la forge elle-même (voir Forges). Si la forge en refuse un, l'erreur s'affiche et les brouillons restent pour une nouvelle tentative. Les fils de revue existants ne sont pas dessinés en ligne sur un commit — leurs positions appartiennent au diff de la demande entière —, mais la conversation est là comme toujours.

GitHub liste au plus 250 commits d'une pull request. Sur une plus longue, le sélecteur le signale sous la liste ; les commits suivants se revoient quand même dans All changes.

Commentaires

Par défaut	Action
⌘↩	commenter la ligne du curseur ou la sélection
⌘E	modifier le brouillon sous le curseur
⌘⌫	supprimer le brouillon sous le curseur
⇧⌘X	écarter ↔ restaurer (conservé ; jamais soumis tant qu'écarté)
⌥⌘↩	suggérer un changement : le code sélectionné prérempli dans un bloc ```suggestion
⌘R	répondre — au fil du serveur ou à la conversation du brouillon
⌘L	le navigateur de revue : chaque brouillon et fil ; Retour saute
⌥↩	ouvrir la conversation sous le curseur dans son propre lecteur
⇧⌘T	déplier ↔ replier le fil résolu sous le curseur
⌃⌘E	modifier le fichier courant localement (voir plus bas)

Une sélection doit tenir sur un seul côté, à la façon de GitHub : un bloc de changements s'ancre à DROITE (les suppressions ne font simplement pas partie de ce côté), une sélection de suppressions seules s'ancre à GAUCHE. Les brouillons se signalent par ● dans la marge, avec la note en ligne ; les fils existants du serveur, par ◆.

Fils obsolètes et résolus

Un fil est obsolète (outdated) quand le code sur lequel il a été écrit a changé depuis, si bien qu'il ne tombe plus sur aucune ligne du diff. Plutôt que de le dessiner à côté du code qui porte aujourd'hui ce numéro de ligne, prchum liste les fils obsolètes en tête de leur fichier, un par ligne — auteur, la ligne où il se trouvait, le début du commentaire. Read… (ou ⌥↩ sur cette ligne) ouvre la conversation entière dans le lecteur, où l'on peut toujours répondre.

Un fil résolu (resolved) qui est encore sur une ligne se replie en une seule ligne sous celle-ci. Expand, ou ⇧⌘T avec le curseur dessus, l'affiche en entier ; Collapse ou ⇧⌘T à nouveau le replie. ⌥↩ l'ouvre dans le lecteur sans le déplier.

Le navigateur de revue (⌘L) liste les deux, étiquetés outdated ou resolved ; Retour saute à un fil qui a une ligne et ouvre celui qui n'en a pas. Le compteur ◆ de la barre latérale les inclut.

Résoudre et rouvrir des fils reste l'affaire du serveur. GitHub n'indique la résolution que par son API GraphQL ; si cette requête échoue, les fils s'affichent en entier plutôt que d'empêcher la revue de s'ouvrir.

Écarter n'est pas supprimer : le verdict voyage avec la revue — c'est l'information dont l'autre côté d'une conversation a le plus besoin — mais un commentaire écarté n'est jamais soumis.

L'édition locale

⌃⌘E ouvre le fichier sous le curseur dans votre éditeur, dans une copie locale de la branche en revue — à la ligne du curseur quand cette ligne existe dans le fichier (une suppression l'ouvre sans ligne).

La copie vient du clone que vous désignez dans la configuration : si la branche y est déjà extraite — dans le clone lui-même ou dans un worktree à vous — c'est celui-là qui sert, intact ; sinon prchum crée son propre worktree à côté de son état, en récupérant la tête de la demande quand la branche n'est pas encore locale. Seuls les worktrees créés par prchum sont supprimés, et seulement quand la demande est fusionnée, fermée ou disparue.

Une comparaison git n'a besoin d'aucun clone : c'est déjà une copie de travail, le fichier s'ouvre sur place.

La soumission

⇧⌘↩ ouvre la feuille de soumission sur une session de pull request ; ⌥⌘A l'ouvre avec Approve présélectionné et ⌥⌘R avec Request changes — la feuille confirme dans tous les cas. Elle montre les décomptes, le sélecteur d'événement (Comment / Approve / Request changes), le résumé et un avertissement explicite pour les commentaires orphelins, qui ne sont jamais soumis. Rien ne part avant cette confirmation.

La soumission résiste aux nouvelles tentatives : l'application enregistre exactement ce que le serveur a accepté, même si une étape ultérieure échoue ; une nouvelle tentative n'envoie que ce qui reste en attente — jamais un doublon.

L'export

⇧⌘E écrit vos notes dans un fichier : du Markdown groupé par fichier, ou — avec un nom en .json — un document d'échange autonome (voir Sources) qui embarque le patch.

Depuis le terminal

Prchum est fait pour être appelé comme on appelle git diff, et prend donc les mêmes formes d'argument :

prchum                  # ce qu'afficherait git diff
prchum --staged         # ce qu'afficherait git diff --staged
prchum main             # cette branche face à main
prchum v1..v2           # un intervalle
prchum change.diff      # un correctif ou un document d'échange
prchum 418              # la demande 418 de l'origin de ce dépôt
prchum owner/repo#418   # un dépôt explicite

git prchum fait la même chose, parce que git traite tout git-* du PATH comme une sous-commande — et il s'exécute depuis la racine du dépôt, donc il veut dire la même chose dans un sous-répertoire qu'à la racine.

Pour en faire la commande réflexe, donnez un alias à git :

git config --global alias.d '!git prchum'

git d ouvre alors ce que git diff aurait imprimé, et git d main compare à une branche.

Les deux commandes ont une page de manuel : man prchum, man git-prchum, et git prchum --help, que git sert depuis cette même page.

Sous macOS la commande s'installe depuis Prchum → Install Command-Line Tool…, ou avec make install-cli depuis un checkout. Sous Linux, les paquets l'installent.

Elle s'appelait pr

Ce qui était une erreur : pr est le paginateur POSIX, il a une page de manuel, et /usr/local/bin passe avant /usr/bin dans le PATH par défaut — l'installer là masquait donc silencieusement un outil standard. Si vous avez l'ancien, rm /usr/local/bin/pr remet les choses en place.