| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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 made the recursive backronym the README title — Pearl Edits and Reflects Linear (P=Pearl, E=Edits, A=and, R=Reflects, L=Linear) — and named it in the opening line, matching the sibling projects' READMEs (Chime, emacs-wttrin). Added an Umberto Eco epigraph, "We like lists because we don't want to die.", in the same quote style they use. The cgit repo description on cjennings.net is set to match.
|
| |
|
|
| |
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.
|
