| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
A grouped view rendered its sections in first-appearance order: whatever order issues came back from the API. So the columns came out scrambled instead of following Linear's board order (Icebox, then In Progress, then Done). Org's own sort couldn't fix it either, since the buffer carried nothing to sort the sections on.
Group sections now order by a per-dimension key. workflowState orders by state type rank (triage, backlog, unstarted, started, completed, canceled), with the state's position breaking ties within a type, so it matches the board. priority orders Urgent down to None last. project, assignee, and cycle have no board order, so they sort alphabetically. One shared helper feeds both the render path and the interactive regroup, so they can't drift.
For the regroup to order without a refetch, the state position has to be in the buffer, so the issue drawer now carries LINEAR-STATE-POSITION (fetched alongside the name and type pearl already pulled). A buffer rendered before this change has no position field and falls back to ordering by type rank alone until its next fetch.
|
| |
|
|
|
|
| |
Phase 4 of the interactive-grouping spec: the integration that makes an interactive grouping survive a refresh. The full render (pearl--build-org-content) and both merge-refresh paths (the dirty-merge branch and pearl--merge-query-result) read the source's grouping straight from :group. I pointed all three at pearl--effective-grouping instead, so a buffer the user grouped by hand redraws the same way rather than snapping back to the view's server grouping.
The swap is backward-compatible: with no :client-group set, the resolver returns :group, so a server-grouped view renders exactly as before. 2 render tests lock both directions: a :client-group overrides the server :group, and a server-only view still groups by :group.
|
| |
|
|
|
|
| |
Phase 3 of the interactive-grouping spec: the command that ties phases 1 and 2 together. pearl-set-grouping completing-reads a dimension (status/project/assignee/priority/none), coerces and validates it, regroups the buffer, then persists the choice on the source. M-x only for now, like pearl-set-sort. The transient and keymap entries come later.
pearl--apply-grouping is the non-interactive core, shaped like pearl--apply-sort. On a successful regroup it re-folds the page and writes :client-group into the header. On an empty buffer it reports no-issues and writes nothing, so a failed grouping never advertises a layout the buffer doesn't show. none ungroups and clears the override. 4 tests cover persistence, the none-clears path, the re-fold, and the no-issues skip.
|
| |
|
|
|
|
|
|
| |
Phase 2 of the interactive-grouping spec: the buffer transform, still no command. pearl--regroup-issue-subtrees re-lays-out the active view's issues by an issueGrouping value, or flattens them when given nil. It moves each issue subtree byte-for-byte and shifts only its heading stars, so descriptions, comments, and unsaved edits ride along untouched. The group label comes from the subtree's own drawer (pearl--buffer-issue-group-label), so the regroup matches a server-grouped render without a refetch.
It works from either starting state. It climbs to the level-1 view parent, captures every issue (level-2 in a flat buffer, level-3 under a group heading in a grouped one) normalized to a canonical level, then re-emits them flat at level 2 or sectioned under level-2 group headings at level 3. Group headings are regenerated, so a stale one never lingers. A non-issue level-2 subtree is kept and placed after the groups rather than dropped.
pearl--shift-heading-levels is the level mechanic, isolated and tested both directions. 29 tests cover the shift, grouping by each dimension, the unset bucket, regrouping to a new dimension, flatten and round-trip, edit preservation, malformed-last, and no-issues.
|
|
|
Phase 1 of the interactive-grouping spec: the source/resolver plumbing, no command yet. pearl--grouping-choices maps the display labels (status/project/assignee/priority/none) to Linear's issueGrouping values. pearl--grouping-display-to-value coerces and pearl--check-grouping validates, both refusing anything outside that set. Cycle is left out on purpose: it isn't in the issue drawer, so an offline regroup can't read it.
pearl--source-with-grouping records the choice under :client-group for every source type, leaving a view's own server :group intact. Choosing none removes the key, so the source falls back to the server :group or to flat. pearl--effective-grouping returns :client-group when set, else :group. That's the single read every grouping consumer routes through in phase 4, so a refresh reproduces the layout on screen.
16 tests: coercion, validation, the source helper, resolver precedence, and the :client-group header round-trip.
|
