diff options
Diffstat (limited to 'README.org')
| -rw-r--r-- | README.org | 30 |
1 files changed, 15 insertions, 15 deletions
@@ -168,10 +168,10 @@ The hot-path commands sit one key under the prefix; the rest are grouped into su | =s= / =S= | save the issue at point / save every issue in the file | | =d= | edit the description | | =m= | open the full transient menu | -| =f= ... | fetch: =s= pick source, =o= open issues, =p= by project, =f= filter, =v= view, =q= saved query | +| =f= ... | fetch: =s= pick source, =o= open issues, =p= by project, =f= filter, =v= view, =q= saved query, =S= sync saved query to Linear, =P= publish current source | | =e= ... | edit: =d= description, =s= state, =a= assignee, =l= labels, =c= comment | | =c= ... | create: =t= issue, =c= comment | -| =k= ... | delete: =t= issue, =c= comment | +| =k= ... | delete: =t= issue, =c= comment, =q= saved query | | =o= ... | open: =i= issue in browser, =v= view in Linear | | =y= ... | copy: =u= issue URL | @@ -188,18 +188,18 @@ With =which-key=, each step shows a labeled menu. Every command is also availabl A *source* is anything Pearl can fetch from: a Linear favorite, a Custom View, a project / cycle / label / user, a local saved query, or an ad-hoc filter. The everyday front door is =pearl-pick-source= (=C-; L f s=, or =P= in the transient), which lists all your Linear favorites first (in their Linear sort order) and then your local saved queries, each tagged by kind: #+begin_example - [view] Active sprint bugs - [project] Orchestration Dashboard - [user] Vrezh Mikayelyan - [label] security - [saved] My open work - [saved → Eng] Active sprint bugs (synced) - [saved → Personal] My ICEBOX scratchpad (synced) + [view] Active sprint bugs + [project] Orchestration Dashboard + [user] Vrezh Mikayelyan + [label] security + [saved] My open work + [saved → Eng] Active sprint bugs (synced) + [saved → Personal] My ICEBOX scratchpad (synced) #+end_example Pick one and it fetches. List-capable favorites (Custom View / project / cycle / label / user) resolve to the existing filter or view fetch and render into the active file; non-list favorites (issue, document, dashboard, ...) open in the browser instead. Favorites are picker entries, never persisted -- a chosen favorite resolves to a concrete filter/view source before rendering, so refresh re-runs that resolved source and stays stable even if your favorites list later changes. Label and user favorites resolve by id, not by name or email, so renames in Linear don't break a saved fetch. -A saved query you've synced up to Linear (see /Publishing a saved query as a Linear view/ below) renders as =[saved → <Team or Personal>] Name= so you can see at a glance which scope it lives in. The arrow reads "where it lives now." Picking it dispatches as a Linear view (server-side filter run via =customView(id:)=), not as a local filter -- any drift you've made to the view on Linear's side is honored. Plain =[saved]= entries are local-only and still run the authoring filter Pearl has on disk. =[saved → ?]= means the entry is synced but Pearl couldn't resolve the team id (deleted or renamed on Linear) -- the dispatch still works, the label is just flagging stale scope metadata. +A saved query you've synced up to Linear (see [[*Publishing a saved query as a Linear view]] below) renders as =[saved → <Team or Personal>] Name= so you can see at a glance which scope it lives in. The arrow reads "where it lives now." Picking it dispatches as a Linear view (server-side filter run via =customView(id:)=), not as a local filter -- any drift you've made to the view on Linear's side is honored. Plain =[saved]= entries are local-only and still run the authoring filter Pearl has on disk. =[saved → ?]= means the entry is synced but Pearl couldn't resolve the team id (deleted or renamed on Linear) -- the dispatch still works, the label is just flagging stale scope metadata. If the favorites fetch fails (network/auth/transport), the picker still offers any local saved queries -- a failed fetch is not the same as "no favorites." With neither favorites nor saved queries, =pearl-pick-source= refuses with a clear message naming the missing setup. @@ -209,10 +209,10 @@ A local saved query is great for your own quick filters, but the team can't see Two commands publish: -| Command | What it does | -|------------------------------------+--------------------------------------------------------------------| -| =pearl-sync-saved-query-to-linear= | Pick a saved query by name and publish (or update) it on Linear | -| =pearl-publish-current-source= | Read the buffer's =#+LINEAR-SOURCE=; if it names a local saved query, publish that one | +| Command | Binding | What it does | +|------------------------------------+--------------------------------------+--------------------------------------------------------------------| +| =pearl-sync-saved-query-to-linear= | =C-; L f S=, =S= in the transient Fetch group | Pick a saved query by name and publish (or update) it on Linear | +| =pearl-publish-current-source= | =C-; L f P=, =U= in the transient Fetch group | Read the buffer's =#+LINEAR-SOURCE=; if it names a local saved query, publish that one | The first time you sync a query, Pearl asks where the view should live with one enriched prompt that spells out the full end-state per option: @@ -334,7 +334,7 @@ A fetched Pearl file is intentionally readable. The header records the source, r The issue description renders here as Org and can be edited in place. - *** 💬 Comments + *** Comments **** Author Name - 2026-05-23T10:00:00.000Z A comment, oldest first. #+end_src |