diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-05 00:56:19 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-05 00:56:19 -0500 |
| commit | 951abea0b2ed07d71676cd4d10ff7c6ca50d1390 (patch) | |
| tree | 6fbe516d9b757e38a5e6e6950f6fe8e4767bf40b /README.org | |
| parent | 387c8a9ff9828d1b024987d136d216ef12c5103f (diff) | |
| download | pearl-951abea0b2ed07d71676cd4d10ff7c6ca50d1390.tar.gz pearl-951abea0b2ed07d71676cd4d10ff7c6ca50d1390.zip | |
feat(views): sort the active view interactively
pearl-set-sort reorders the current view by updated, created, priority, or title without hand-editing a source. pearl-toggle-sort-order flips asc/desc on the current sort, defaulting to updated descending. Both are M-x for now. The spec deferred a key binding until the menu layout settles.
Priority and title sort client-side: pearl--reorder-issue-subtrees moves whole issue subtrees by LINEAR-ID, byte-for-byte, so unsaved description and comment edits survive and a non-issue heading is kept rather than dropped. Updated and created refetch with the new server orderBy. The #+LINEAR-SOURCE header is rewritten only after the reorder or refetch succeeds, so a failed sort never advertises an order the buffer doesn't show.
Two things the 2026-05-24 spec predates and I had to settle. A view's :sort now holds Linear's IssueSortInput, so the interactive sort on a view persists under separate :client-sort/:client-order keys and pearl--effective-sort-order re-applies it on refresh. That keeps a view sort surviving a refresh the same way a filter sort does, rather than behaving differently on a distinction the user can't see. Grouped views aren't reorderable in place yet. They refuse with a message. A created/updated sort on a Custom View is refused too, since Linear gives views no server-side order.
Diffstat (limited to 'README.org')
| -rw-r--r-- | README.org | 6 |
1 files changed, 6 insertions, 0 deletions
@@ -295,6 +295,12 @@ Sorting is local and deterministic. Query filters are AND-only; use a Linear Cus =pearl-refresh-current-view= merges the fresh fetch into the buffer by issue id rather than rebuilding it: issues update in place, new matches are appended, and ones no longer in the result are dropped. Your view survives: point and the fold state of every untouched issue stay put, and only the subtrees that actually changed get re-folded. Editing an issue and refreshing won't collapse the subtree you were working in or scroll you back to the top. +*** Sorting the current view + +=pearl-set-sort= reorders the active view without hand-editing a source. It asks for a key (=updated=, =created=, =priority=, =title=) and an order (=desc= / =asc=). =pearl-toggle-sort-order= flips the order on the current sort, defaulting to =updated= descending when nothing is set yet. + +Priority and title sort the fetched issues in place: whole subtrees move by id, so unsaved edits survive, and the order sticks across a refresh. Updated and created refetch with the new server ordering. A Custom View has no server-side order in Linear's API, so =updated= / =created= are refused on a view -- sort it by priority or title instead, which still reorders the issues it returned. Sorting a grouped view in place isn't supported yet. Both commands are =M-x= for now. A key binding lands once the menu layout settles. + *** Editing issues Pearl has one write path. Edit an issue however you like in the buffer, then save it -- Pearl diffs each field against what it last fetched and pushes only what changed. Nothing pushes the moment you pick a value, and there is no per-field "push" command to remember. All issue commands work from anywhere inside an issue subtree. |