fix: signal loading with 'busy' instead of writing into the buffer #14

Merged
barrettruth merged 2 commits from fix/no-loading-text into main 2026-07-27 22:39:24 +00:00
Owner

Checklist

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

Problem

Errors already went to :messages rather than into the buffer, but the loading
placeholder was still written as buffer content:

M.set(buf, { u.kind == 'job' and 'Loading job log...' or 'Loading checks...' })

That is the same category of mistake, and it was worse than cosmetic. On a
refresh it overwrote what you were reading before the fetch had returned
anything, and a refresh that then failed left the buffer reading Loading job log... permanently — M.fail only cleared for a buffer that had never loaded,
so a buffer that had loaded kept the placeholder instead of its log.

Solution

'busy' is the option for this. Nothing is written until the content itself
arrives.

A first open starts empty. A refresh keeps the old text on screen until the new
text replaces it, and keeps it for good if the fetch fails, which is what the
buffer promised all along.

during load: busy=1 lines={ "" }
after load : busy=0 lines=2563
after fail : busy=0 lines=2563   (content kept)

vim.bo.busy exists on the supported floor. guh.nvim pairs it with progress
messages, but those need nvim_echo's kind="progress", which guh can rely on
because it requires 0.13+ and we cannot.

## 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. ## Problem Errors already went to `:messages` rather than into the buffer, but the loading placeholder was still written as buffer content: ```lua M.set(buf, { u.kind == 'job' and 'Loading job log...' or 'Loading checks...' }) ``` That is the same category of mistake, and it was worse than cosmetic. On a refresh it overwrote what you were reading before the fetch had returned anything, and a refresh that then failed left the buffer reading `Loading job log...` permanently — `M.fail` only cleared for a buffer that had never loaded, so a buffer that *had* loaded kept the placeholder instead of its log. ## Solution `'busy'` is the option for this. Nothing is written until the content itself arrives. A first open starts empty. A refresh keeps the old text on screen until the new text replaces it, and keeps it for good if the fetch fails, which is what the buffer promised all along. ``` during load: busy=1 lines={ "" } after load : busy=0 lines=2563 after fail : busy=0 lines=2563 (content kept) ``` `vim.bo.busy` exists on the supported floor. `guh.nvim` pairs it with progress messages, but those need `nvim_echo`'s `kind="progress"`, which guh can rely on because it requires 0.13+ and we cannot.
fix: signal loading with 'busy' instead of writing into the buffer
All checks were successful
quality / Test (pull_request) Successful in 6s
quality / Lint (pull_request) Successful in 10s
quality / Format (pull_request) Successful in 10s
c72dbcad0a
The buffer holds the log, and nothing else. Errors already went to :messages
rather than into the content; the placeholder was the last piece of chrome
still being written there, and it was worse than cosmetic. On a refresh it
overwrote what you were reading, and a refresh that then failed left the
buffer reading "Loading job log..." forever, because M.fail only cleared for
a buffer that had never loaded.

Now nothing is written until the content itself arrives, so a first open
starts empty and a refresh keeps the old text on screen until the new text
replaces it, or keeps it for good if the fetch fails.
feat: name the repository in the winbar, and colour the rollup
All checks were successful
quality / Test (pull_request) Successful in 6s
quality / Lint (pull_request) Successful in 9s
quality / Format (pull_request) Successful in 9s
f0c962995a
Two log buffers from different repositories both read "LOG ✓ Analyze |
codeql", which is no help when both are open. b:ci.repo was already populated
and simply unused.

The checks list set status_hl and then never read it, because its winbar
printed the whole header through b:ci.title. Splitting the rollup summary out
into b:ci.status gives the two buffer kinds the same shape — status is the
coloured state, title is the name — and puts the field to work: "20 running,
2 pending, 7/29 passing" now carries the worst bucket's colour.

The separator lives inside the status expression rather than in a %( %) group
around it, because a group containing %{%…%} is treated as empty and drops the
whole segment. guh keeps its status out of such a group for the same reason.
barrettruth deleted branch fix/no-loading-text 2026-07-27 22:39:24 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
barrettruth/ci.nvim!14
No description provided.