| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The comment overlay started at the line beginning, so it sat on top of the leading stars. With a package like org-superstar that dims those stars (and composes a bullet from them) via a face, our overlay's face overrode it and the dimmed stars reappeared in our color, a stray "***" before the bullet. The darker, body-spanning read-only overlay made it obvious, but the overlay had covered the stars since comment highlighting first landed.
I start the overlay just past the leading stars now (the point right after the `^\*+ ` match), so the stars and the bullet keep org's own fontification and only the heading text and body get our face. The highlight tests check the face on the heading text and assert the stars are left uncovered.
|
| |
|
|
| |
A comment you can't edit only had a grey heading, and the grey (`shadow`) was light enough to blend with the body text of your own comments. Now the read-only overlay covers the whole comment subtree, heading and body, so the comment recedes as a unit. And `pearl-readonly-comment` uses a darker background-aware grey (gray40 on a dark theme, gray60 on light, `shadow` as the fallback). Editable comments keep the heading-only overlay so your own comment text stays normal-colored, with the green heading as the "this one's yours" cue.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
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".
|
| |
|
|
| |
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.
|
| |
|
|
| |
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.
|
|
|
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.
|
