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 /tests/test-pearl-fetch-all-comments.el | |
| 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 'tests/test-pearl-fetch-all-comments.el')
0 files changed, 0 insertions, 0 deletions
