| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Setting a sort order opened every issue, drawer, and comment in the buffer. The reorder moves subtrees by deleting the issue block and re-inserting it, and freshly inserted Org text comes in fully expanded. The fold state lives in overlays that delete-and-insert drops. Neither sort path re-folded afterward, unlike the full-render and merge paths, which already do.
Both sort paths now call pearl--restore-page-visibility after a successful reorder, re-folding the page to its #+STARTUP visibility so it stays the scannable outline it was before the sort. A refusal (a grouped buffer or a failed refetch) moves nothing, so it doesn't re-fold. The behavior honors pearl-fold-after-update like the other repopulating paths.
|
| |
|
|
|
|
| |
The #+LINEAR-SOURCE descriptor was written with a bare prin1-to-string, which honors the user's print-length and print-level. A long source, like a Custom View's (it carries a sort vector, a url, and several keys), truncated to "..." for anyone whose config caps those (mine sits at 10). The header then read back as a malformed, odd-length plist, so refresh and the new sort commands errored on the view. A short source like my-open-issues fit under the cap and hid the bug.
pearl--linear-source-string binds both to nil around the serialization, and the two header writers (the full render and the sort header rewrite) go through it. I caught it dogfooding the interactive sort live on a real view.
|
| |
|
|
|
|
| |
A server-side sort (updated/created) refetched with the new orderBy and merged the result, but the merge updates issues in place by id and never moves them, so the buffer kept its old order and the sort had no visible effect. I caught it dogfooding live: sorting My Open Issues updated-ascending then updated-descending rendered an identical order.
After the refetch I now reorder the buffer's issue subtrees to the fetched order. pearl--issue-id-ranks builds a LINEAR-ID to position map from the sorted result, and pearl--reorder-issue-subtrees takes an optional id-ranking and lays the subtrees out by it. The move is the same byte-for-byte subtree shuffle the client-side sort already uses, so unpushed edits survive. Re-checked live: updated-ascending now comes back the exact reverse of updated-descending.
|
|
|
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.
|
