benstull/vscode-cowriting-plugin
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Ask Claude to Edit Document — whole-document edit from body (no selection) + tab right-click #42

New Issue
Closed
opened 2026-06-12 15:57:31 +00:00 by benstull · 1 comment
benstull commented 2026-06-12 15:57:31 +00:00
Owner
Copy Link
Copy Source

Summary

"Ask Claude to Edit" is reachable by right-click whether or not text is
selected, and from the editor tab: right-clicking the document body with no
selection offers a new "Ask Claude to Edit Document" (whole-document edit),
and right-clicking the editor tab offers "Ask Claude to Edit Selection"
when text is selected or "Ask Claude to Edit Document" when it isn't.

Problem / pain

Asking Claude to edit is currently only offered in the editor body and only
when text is selected (cowriting.editSelection, "Ask Claude to Edit
Selection", gated on editorHasSelection). Two natural gestures get nothing:

  • Right-clicking the body with no selection — the writer wants Claude to work
    on the whole document but there is no affordance for it (and no
    whole-document edit command exists at all).
  • Right-clicking the editor tab — the muscle-memory "do something with this
    document" gesture — offers no "Ask Claude to Edit" entry, selection or not.

So a writer who wants a document-level edit, or who reaches for the tab, hits a
dead end.

Who feels it

Writers using the plugin to co-edit a document with Claude — especially anyone
who wants a whole-document pass rather than a selection-scoped one, and
tab-oriented / mouse-first users.

Desired outcome / value

A consistent "Ask Claude to Edit" entry point: selection-scoped when there's a
selection, whole-document when there isn't, available both in the body and on
the tab. Adds the missing whole-document edit capability and makes both
scopes discoverable from the obvious right-click gestures.

Acceptance — "done right"

  • Right-clicking the document body with no selection shows "Ask Claude to
    Edit Document"    , which asks Claude to edit the entire document and surfaces
    the result through the existing F4 propose/accept seam.
  • Right-clicking the document body with a selection continues to show "Ask
    Claude to Edit Selection"     (unchanged behavior).
  • Right-clicking the editor tab shows "Ask Claude to Edit Selection" when
    the document has an active selection, otherwise "Ask Claude to Edit
    Document"    , each invoking the same behavior as the body equivalents against
    that document.
  • Both entries appear only for markdown / authorable documents, consistent
    with the existing editSelection when clause (resourceScheme == file || untitled).
  • Whole-document edits route through the same attribution + propose/accept
    machinery as selection edits (no separate, divergent edit path).
  • E2E browser coverage asserts: edit-document item appears with no selection,
    edit-selection item appears with a selection, both appear on the tab per
    selection state, and each produces a proposal.

Scope / non-goals

  • In scope: a new whole-document edit command (e.g.
    cowriting.editDocument); editor/context wiring for the no-selection case;
    editor/title/context (tab) wiring for both selection states; reuse of the
    existing edit → propose/accept seam.
  • Non-goals: no change to how selection edits already work; no Explorer
    context-menu entry (tab + body only, per the ask); no new proposal-granularity
    model — whole-doc edits use the existing F4 mechanics; no multi-file / batch
    document editing.

Assumptions · constraints · dependencies

  • cowriting.editSelection already exists and routes edits through the F4
    propose/accept seam (whole-proposal granularity); a whole-document edit is the
    same flow with the range spanning the entire document.
  • Open questions for the design step: how the edit instruction is gathered for
    a whole-document edit (reuse the selection-edit prompt?); whether a full-document
    rewrite surfaces as one large proposal or several; behavior/expectations on
    large documents (token limits). These are why this is a feature, not a bare
    story.
  • VS Code context menus render the command's own title; the tab menu shows one
    of two commands chosen by a when clause on selection state (no per-menu
    dynamic relabel of a single command).
  • Related lineage: the F3 attribution + F4 propose/accept inner loop this rides
    on; sibling discoverability ask in this same capture session (review-panel
    right-click entry).

Source / signal

Self-originated — capture session vscode-cowriting-plugin-0035 (operator ask:
"Add 'Ask Claude to Edit Document' in the context menu when right-clicking the
body with no text selected; the same Edit Selection / Edit Document should be in
the context menu when right-clicking the tab").

Priority (WSJF)

Value (med — adds whole-document editing + closes two dead-end gestures) ·
Time-criticality (low) · Opportunity-enablement (low–med, a new edit scope) ÷
Size (small) → modest-but-favorable score. priority/P2.

Decomposition

  • New cowriting.editDocument command — ask Claude to edit the whole document, routed through the existing edit → F4 propose/accept seam.
  • editor/context (body) wiring: show Edit Document when !editorHasSelection, keep Edit Selection when editorHasSelection.
  • editor/title/context (tab) wiring: show Edit Selection when there's a selection, else Edit Document, against the tab's document.
  • Confirm whole-document edits reuse the attribution + propose/accept path (no divergent edit code).
  • E2E coverage: body no-selection, body selection, tab both states, proposal produced.

Solution notes (optional — NOT a design)

The cleanest shape is a thin editDocument command that constructs a
full-document range and calls the same edit entry point editSelection uses, so
attribution and propose/accept are shared. The tab menu is two commands gated by
editorHasSelection (or the closest tab-context equivalent), not one command that
relabels itself. Non-binding — the design step settles instruction-gathering and
proposal-granularity for whole-document edits.

<!-- Set the type/* label via capture-issues.sh --type feature --> ## Summary **"Ask Claude to Edit"** is reachable by right-click whether or not text is selected, and from the editor tab: right-clicking the **document body with no selection** offers a new **"Ask Claude to Edit Document"** (whole-document edit), and right-clicking the **editor tab** offers **"Ask Claude to Edit Selection"** when text is selected or **"Ask Claude to Edit Document"** when it isn't. ## Problem / pain Asking Claude to edit is currently only offered **in the editor body and only when text is selected** (`cowriting.editSelection`, *"Ask Claude to Edit Selection"*, gated on `editorHasSelection`). Two natural gestures get nothing: - **Right-clicking the body with no selection** — the writer wants Claude to work on the *whole document* but there is no affordance for it (and no whole-document edit command exists at all). - **Right-clicking the editor tab** — the muscle-memory "do something with this document" gesture — offers no "Ask Claude to Edit" entry, selection or not. So a writer who wants a document-level edit, or who reaches for the tab, hits a dead end. ## Who feels it Writers using the plugin to co-edit a document with Claude — especially anyone who wants a whole-document pass rather than a selection-scoped one, and tab-oriented / mouse-first users. ## Desired outcome / value A consistent "Ask Claude to Edit" entry point: **selection-scoped when there's a selection, whole-document when there isn't**, available both in the body and on the tab. Adds the missing **whole-document edit** capability and makes both scopes discoverable from the obvious right-click gestures. ## Acceptance — "done right" - Right-clicking the **document body with no selection** shows **"Ask Claude to Edit Document"**, which asks Claude to edit the **entire document** and surfaces the result through the existing F4 propose/accept seam. - Right-clicking the **document body with a selection** continues to show **"Ask Claude to Edit Selection"** (unchanged behavior). - Right-clicking the **editor tab** shows **"Ask Claude to Edit Selection"** when the document has an active selection, otherwise **"Ask Claude to Edit Document"**, each invoking the same behavior as the body equivalents against that document. - Both entries appear **only for markdown / authorable** documents, consistent with the existing `editSelection` `when` clause (`resourceScheme == file || untitled`). - Whole-document edits route through the same attribution + propose/accept machinery as selection edits (no separate, divergent edit path). - E2E browser coverage asserts: edit-document item appears with no selection, edit-selection item appears with a selection, both appear on the tab per selection state, and each produces a proposal. ## Scope / non-goals - **In scope:** a new whole-document edit command (e.g. `cowriting.editDocument`); `editor/context` wiring for the no-selection case; `editor/title/context` (tab) wiring for both selection states; reuse of the existing edit → propose/accept seam. - **Non-goals:** no change to how selection edits already work; no Explorer context-menu entry (tab + body only, per the ask); no new proposal-granularity model — whole-doc edits use the existing F4 mechanics; no multi-file / batch document editing. ## Assumptions · constraints · dependencies - `cowriting.editSelection` already exists and routes edits through the F4 propose/accept seam (whole-proposal granularity); a whole-document edit is the same flow with the range spanning the entire document. - Open questions for the design step: how the edit **instruction** is gathered for a whole-document edit (reuse the selection-edit prompt?); whether a full-document rewrite surfaces as **one large proposal** or several; behavior/expectations on **large documents** (token limits). These are why this is a feature, not a bare story. - VS Code context menus render the command's own `title`; the tab menu shows one of two commands chosen by a `when` clause on selection state (no per-menu dynamic relabel of a single command). - Related lineage: the F3 attribution + F4 propose/accept inner loop this rides on; sibling discoverability ask in this same capture session (review-panel right-click entry). ## Source / signal Self-originated — capture session **vscode-cowriting-plugin-0035** (operator ask: "Add 'Ask Claude to Edit Document' in the context menu when right-clicking the body with no text selected; the same Edit Selection / Edit Document should be in the context menu when right-clicking the tab"). ## Priority (WSJF) Value (med — adds whole-document editing + closes two dead-end gestures) · Time-criticality (low) · Opportunity-enablement (low–med, a new edit scope) ÷ Size (small) → modest-but-favorable score. `priority/P2`. ## Decomposition - [ ] New `cowriting.editDocument` command — ask Claude to edit the whole document, routed through the existing edit → F4 propose/accept seam. - [ ] `editor/context` (body) wiring: show **Edit Document** when `!editorHasSelection`, keep **Edit Selection** when `editorHasSelection`. - [ ] `editor/title/context` (tab) wiring: show **Edit Selection** when there's a selection, else **Edit Document**, against the tab's document. - [ ] Confirm whole-document edits reuse the attribution + propose/accept path (no divergent edit code). - [ ] E2E coverage: body no-selection, body selection, tab both states, proposal produced. ## Solution notes (optional — NOT a design) The cleanest shape is a thin `editDocument` command that constructs a full-document range and calls the same edit entry point `editSelection` uses, so attribution and propose/accept are shared. The tab menu is two commands gated by `editorHasSelection` (or the closest tab-context equivalent), not one command that relabels itself. Non-binding — the design step settles instruction-gathering and proposal-granularity for whole-document edits.
benstull added the type/featurepriority/P2 labels 2026-06-12 15:57:31 +00:00
benstull commented 2026-06-13 14:27:52 +00:00
Author
Owner
Copy Link
Copy Source

Shipped as SLICE-1 of the document-edit flow (#49, session 0043). Selection-aware Ask Claude to Edit is now reachable from the editor body and the editor tab (selection → Edit Selection; no selection → Edit Document), markdown/authorable-gated, both through the single runEditAndPropose path (INV-38). 208 unit + 65/5 host E2E green.

Shipped as SLICE-1 of the document-edit flow (#49, session 0043). Selection-aware **Ask Claude to Edit** is now reachable from the editor body and the editor tab (selection → Edit Selection; no selection → Edit Document), markdown/authorable-gated, both through the single `runEditAndPropose` path (INV-38). 208 unit + 65/5 host E2E green.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
priority/P0
Priority: highest — drop everything
 priority/P1
Priority: high
 priority/P2
Priority: medium
 priority/P3
Priority: low / someday
 type/bug
A defect in shipped behavior
 type/epic
Type: a large body of work spanning many features
 type/feature
Type: a deliverable capability under an epic
 type/story
Type: a user story — the smallest valuable increment
 type/task
Type: a concrete unit of work under a story
No Label priority/P2 type/feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benstull
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#43 Preview toolbar as the primary interaction surface — adaptive "Ask Claude…" + Pin baseline buttons
benstull/vscode-cowriting-plugin
Reference: benstull/vscode-cowriting-plugin#42
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?