feat: render annotations the way github.com does #33

Merged

barrettruth merged 2 commits from feat/github-band into main

2026-07-28 03:27:10 +00:00

barrettruth commented

2026-07-28 03:11:11 +00:00

Owner

Checklist

I have read CONTRIBUTING.md.
No AI was used to generate, edit, or review any part of this contribution.

Supersedes #32, which is closed. Two commits: the label, then the band.

Problem

##[error] and ##[warning] are markers, not text. The raw byte is

2026-07-27T13:46:55.3331680Z ##[error]Process completed with exit code 1.

There is no "Error" in the log and no ANSI on the line — the word, the bold, the
red fill and the ordinary-white message are all github.com's rendering of that
marker. We concealed the marker, tinted the whole line one colour, and dropped
the word.

Its blocks also run past the marker. A single Homebrew warning in one
neovim/neovim job is eighteen lines, only the first of which carries a
timestamp; we rendered the other seventeen as unrelated output.

Solution

225  ##[warning]The following…   CiAttentionBand/eol  virt="Warning: "
226                              CiAttentionBand/eol
227                              CiAttentionBand/eol
228  g formulae, casks and com   CiAttentionBand/eol
229                              CiAttentionBand/eol

feat: draw the word … (+19/-6) — the label as inline virtual text where
the marker was, sharing one extmark with the indent already at that column so
the two cannot fight over ordering. The same substitution gS makes when it
shows Mon, 27 Jul 2026 15:14:08 GMT for the ISO stamp. Bytes untouched, so
yanking still gives ##[error]….

feat: band annotations … (+79/-4) — everything else:

A mixed background. No Neovim group carries a severity fill —
DiagnosticVirtualTextError links back to DiagnosticError, and ErrorMsg
is foreground-only — and the foreground is a light tint (#ffc0b9) unusable
as one. Mixed 18% from Normal.bg: #3e3537 and #3e3a31.
ColorScheme and OptionSet background autocommands, since a mixed colour
is stale the moment either changes.
A silent fallback where Normal.bg is unset, as on a transparent terminal.
hl_eol and an explicit priority, so the fill reaches the window edge and
sits under the log's own ANSI spans rather than erasing them.
The band on the virtual text too; an extmark's hl_group does not colour
virtual text, so the indent would otherwise leave a two-column hole.
Severity held across untimestamped lines, so a whole block bands.
CiBold, because the label is bold on the web.

What this costs, plainly

+95/-7 on a 2173-line plugin, so a little over 4%, and log.lua goes from 468
to 521. Four new highlight groups, two of which cannot be links and must be
recomputed. The first place the plugin cares what colour your editor is. A
goto in the parse loop.

And it is still not github.com's red — it is a red mixed from your
colourscheme. Theirs would mean hardcoding their palette and ignoring your
theme.

## Checklist - [x] I have read [CONTRIBUTING.md](https://forge.barrettruth.com/barrettruth/ci.nvim/src/branch/main/CONTRIBUTING.md). - [ ] No AI was used to generate, edit, or review any part of this contribution. Supersedes #32, which is closed. Two commits: the label, then the band. ## Problem `##[error]` and `##[warning]` are markers, not text. The raw byte is ``` 2026-07-27T13:46:55.3331680Z ##[error]Process completed with exit code 1. ``` There is no "Error" in the log and no ANSI on the line — the word, the bold, the red fill and the ordinary-white message are all github.com's rendering of that marker. We concealed the marker, tinted the whole line one colour, and dropped the word. Its blocks also run past the marker. A single Homebrew warning in one `neovim/neovim` job is **eighteen lines**, only the first of which carries a timestamp; we rendered the other seventeen as unrelated output. ## Solution ``` 225 ##[warning]The following… CiAttentionBand/eol virt="Warning: " 226 CiAttentionBand/eol 227 CiAttentionBand/eol 228 g formulae, casks and com CiAttentionBand/eol 229 CiAttentionBand/eol ``` **`feat: draw the word …`** (+19/-6) — the label as inline virtual text where the marker was, sharing one extmark with the indent already at that column so the two cannot fight over ordering. The same substitution `gS` makes when it shows `Mon, 27 Jul 2026 15:14:08 GMT` for the ISO stamp. Bytes untouched, so yanking still gives `##[error]…`. **`feat: band annotations …`** (+79/-4) — everything else: - A mixed background. No Neovim group carries a severity fill — `DiagnosticVirtualTextError` links back to `DiagnosticError`, and `ErrorMsg` is foreground-only — and the foreground is a light tint (`#ffc0b9`) unusable as one. Mixed 18% from `Normal.bg`: `#3e3537` and `#3e3a31`. - `ColorScheme` and `OptionSet background` autocommands, since a mixed colour is stale the moment either changes. - A silent fallback where `Normal.bg` is unset, as on a transparent terminal. - `hl_eol` and an explicit priority, so the fill reaches the window edge and sits *under* the log's own ANSI spans rather than erasing them. - The band on the virtual text too; an extmark's `hl_group` does not colour virtual text, so the indent would otherwise leave a two-column hole. - Severity held across untimestamped lines, so a whole block bands. - `CiBold`, because the label is bold on the web. ## What this costs, plainly +95/-7 on a 2173-line plugin, so a little over 4%, and `log.lua` goes from 468 to 521. Four new highlight groups, two of which cannot be links and must be recomputed. The first place the plugin cares what colour your editor is. A `goto` in the parse loop. And it is still not github.com's red — it is *a* red mixed from your colourscheme. Theirs would mean hardcoding their palette and ignoring your theme.

barrettruth added 1 commit

2026-07-28 03:11:11 +00:00

feat: band annotations the way github.com does 24b7cfdc21

Problem: github.com fills an annotation's line with a dark red or yellow and
leaves the words in the ordinary foreground, while we tinted the words and
drew no fill. Its blocks also run past the marker onto continuation lines
that carry no timestamp, which we rendered as unrelated output.

Solution: Two background groups are mixed from the severity colour and the
window background, since no Neovim group carries a severity fill, and the
severity is held across untimestamped lines so a whole block is banded.

barrettruth changed title from ~~feat: band annotations the way github.com does~~ to feat: render annotations the way github.com does

2026-07-28 03:22:26 +00:00

barrettruth changed target branch from feat/marker-labels to main

2026-07-28 03:22:26 +00:00

barrettruth merged commit 2e53d1def9 into main

2026-07-28 03:27:10 +00:00

barrettruth deleted branch feat/github-band

2026-07-28 03:27:11 +00:00

barrettruth referenced this pull request from a commit

2026-07-28 03:27:12 +00:00

feat: render annotations the way github.com does (#33)