aboutsummaryrefslogtreecommitdiff
path: root/tests/test-pearl-comment-editing.el
Commit message (Collapse)AuthorAgeFilesLines
* fix(comments): apply comment highlighting on the bulk render pathCraig Jennings2026-05-261-0/+38
| | | | | | 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.
* refactor: rename pearl--issue-body-at-point to pearl--entry-body-at-pointCraig Jennings2026-05-251-2/+2
| | | | The helper returns the body of the Org entry at point, before any child heading. It started out reading issue descriptions, but comment editing and deletion reuse it for comment bodies too, so "issue" in the name was misleading. I renamed it across its callers and the sync/refresh/save/comment tests, and reworded the docstring to say "entry".
* test: cover comment insertion and extraction boundary casesCraig Jennings2026-05-241-0/+28
| | | | Added ERT tests: append targets the current issue's Comments subtree even when a later issue already has its own Comments; add-comment from inside a comment subtree refuses (no issue id at that heading); edit-current-comment refuses a comment missing LINEAR-COMMENT-ID with no network call; and a comment body containing drawer-looking (:note:) text reads back intact. 380 tests green.
* test: cover sync-back push-failure branches at the command levelCraig Jennings2026-05-241-0/+20
| | | | Added ERT tests that the three sync commands leave provenance untouched when the push fails (:success nil): pearl-sync-current-issue keeps LINEAR-DESC-SHA256 and -UPDATED-AT, pearl-sync-current-issue-title keeps LINEAR-TITLE-SHA256, and pearl-edit-current-comment keeps LINEAR-COMMENT-SHA256 — and in each case the edited text stays in the buffer for retry. Each test asserts the push was attempted with the rendered text. The commands already behave correctly; this locks it. 360 tests green.
* feat: pearl — manage Linear issues from org-modeCraig Jennings2026-05-241-0/+240
Pearl fetches Linear issues into an org file and syncs edits back. It covers list / custom views / saved queries, per-issue and bulk rendering with comments inline, conflict-aware sync of descriptions, titles, and comments, field commands for priority / state / assignee / labels, and a transient dispatch menu. The render folds to a scannable outline and nests issues under a sortable parent. Based on and inspired by Gael Blanchemain's linear-emacs.