diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-26 12:48:22 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-26 12:48:22 -0500 |
| commit | 052aef8689af897c20e02d069fcdb09490996d2d (patch) | |
| tree | a5b3e4f823b76a344edc611ee95fa8148cbf452a /tests/Makefile | |
| parent | 914ab07da513daebd15c7bc65ac334cde5fbb769 (diff) | |
| download | pearl-052aef8689af897c20e02d069fcdb09490996d2d.tar.gz pearl-052aef8689af897c20e02d069fcdb09490996d2d.zip | |
fix(comments): apply comment highlighting on the bulk render path
Comment headings only got their green (editable) / grey (read-only) coloring after `pearl-refresh-current-issue`, an add-comment, or a view merge (the three paths that call `pearl-highlight-comments`). A plain `pearl-list-issues` rendered through `pearl--update-org-from-issues`, which never called it, so a fresh fetch showed no coloring until I refreshed.
I added the highlight call to branches A and B of `pearl--update-org-from-issues`, right after the content lands in the buffer. Branch C defers a dirty buffer without writing, so it stays uncolored. The regression test renders the comment fixture and asserts both headings carry the editability overlay (own to editable, other's to read-only) straight from the bulk render.
Diffstat (limited to 'tests/Makefile')
0 files changed, 0 insertions, 0 deletions
