| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
I added pearl-comment-sort-order to choose how an issue's comments render under the Comments heading: newest-first (the default, most recent on top) or oldest-first (chronological, like an email thread). Both the render sort and the add-comment insertion point honor it, so a new comment lands at the top for newest-first and at the bottom for oldest-first.
|
| |
|
|
|
|
|
|
|
|
| |
The minibuffer is too cramped to write a real comment or description. I added a shared compose buffer: a focused Org buffer with a read-only instructional header at the top (like a git commit template) and an editable body below, where C-c C-c submits and C-c C-k cancels. It's the sibling of the smerge conflict buffer, built the same way.
Two commands use it. pearl-add-comment, run interactively, now opens the composer and converts the Org body to Markdown before sending. Called with an explicit body (tests, programmatic callers), it still sends that directly. pearl-compose-current-description is new: it pops the issue's current description into the composer and, on submit, writes it back into the body and syncs through the existing conflict gate. Both work from anywhere inside an issue subtree.
The header is genuinely uneditable: read-only text properties, with only the last character rear-nonsticky so the body stays editable while edits inside the header are refused. The body is everything below it, extracted by a marker.
I left pearl-new-issue on the minibuffer for now. Wiring its description into the composer means restructuring that long, untested interactive flow to defer the create into the submit callback, which is worth doing on its own rather than riding along here. Filed as a follow-up.
|
| |
|
|
|
|
|
|
| |
A populated list used to look like nothing had comments, because only a single-issue refresh fetched them. The bulk and Custom View queries now pull each issue's most recent comments and render them under the Comments heading, with a marker showing how many are shown against the total: 💬 5/18, or 💬 5/25+ once the count passes the cap.
Linear's API has no comment total (no commentCount on Issue, no totalCount on the connection), so I fetch one more than pearl-list-comments-count-cap newest-first: that gives an exact total up to the cap and a "+" beyond it, in a single round trip. pearl-list-comments-shown (default 5) caps how many render. pearl-fetch-comments-in-list (default on) turns the whole thing off to keep the fetch light. The single-issue refresh still shows the full thread, uncapped and unmarked.
The marker sits on the Comments heading rather than the issue title, so it stays out of the title-sync hash. I relaxed the append locator to match a marked heading, so adding a comment still finds the existing subtree instead of creating a second one. Verified live: the capped fragment is accepted and the markers render correctly.
|
| |
|
|
|
|
| |
I added two display-only heading tweaks, each a defcustom defaulting on. pearl-show-identifier-in-heading prefixes the title with the Linear identifier (** TODO [#B] SE-401: Fix the Bug). pearl-title-case-headings renders the title in smart title case, keeping minor words lowercase unless first or last and leaving words that already carry an uppercase letter (acronyms, identifiers) untouched.
Both stay display-only. The LINEAR-TITLE-SHA256 hash covers the rendered (cased, un-prefixed) title, and the title-sync reader strips the identifier prefix before hashing, so an unedited heading is a no-op and neither the casing nor the prefix ever pushes to Linear. A render-then-read round-trip test locks that invariant.
|
| |
|
|
| |
pearl-new-issue was 129 lines — long but linear (a run of creation prompts), and untested since it is eight interactive reads. I pulled out the one intricate, self-contained piece: the issue-type label selection that groups labels by their " - " category prefix and does the two-stage category-then-label pick. It is now pearl--read-issue-label, called for selected-type. Verbatim move, no logic change; new-issue drops to 93 lines. 353 tests green.
|
| |
|
|
| |
set-priority, set-state, set-assignee, and set-labels each repeated the same tail: push the issueUpdate field, and on success update the heading or drawer at the marker, message, and surface the buffer; on failure, message. I pulled that into pearl--push-issue-field, which takes the fields alist, a success thunk (the per-field buffer update), and the two messages. Each command keeps its own completion source, guards, and id resolution. No behavior change; 353 tests green.
|
| |
|
|
| |
The description, title, and comment syncs each carried the same :noop / :conflict / :push dispatch — only the hash property, the local-text source, the fetch and push functions, the apply step, and the status messages differed. I pulled the dispatch into pearl--commit-sync-decision, which takes a spec plist for the varying parts (description alone advances LINEAR-DESC-UPDATED-AT, via :after-push). The three commands now build a spec and call it, and the comment's own-comment permission check stays in its caller. No behavior change — 353 tests green, including the sync, title-sync, comment-editing, and conflict suites.
|
| |
|
|
| |
The guard `(unless (ignore-errors (org-back-to-heading t) t) (user-error ...))` was copy-pasted across ten issue-at-point commands. I pulled it into pearl--goto-heading-or-error, which takes an optional message so the one comment-specific variant ("Not on a Linear comment") still reads right. Same point move, same user-error type and text — no behavior change; 353 tests green.
|
| |
|
|
| |
The variable was only ever declared and set to nil in pearl-clear-cache — never populated or read anywhere. I removed the defvar, the clear-cache line, and the stale "issues" mention in that docstring. No behavior change; the suite stays at 353 green.
|
| |
|
|
| |
I rewrote the README into a sectioned guide — a nav header over Features, Installation, Quick Start, Commands, The Org File, Configuration, Development & Testing, FAQ, Troubleshooting, History, and License — and repointed every repository URL off the deleted github.com/cjennings/pearl onto https://git.cjennings.net/pearl.git. The repoint also covers the URL header in pearl.el, the Eask website-url, and the package-summary repo link. The upstream credit to Gael Blanchemain's linear-emacs is unchanged.
|
|
|
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.
|
