Skip to content

fix(docs): default docs insert --index to end-of-doc#610

Open
chrischall wants to merge 2 commits into
openclaw:mainfrom
chrischall:fix/606-docs-insert-default-end
Open

fix(docs): default docs insert --index to end-of-doc#610
chrischall wants to merge 2 commits into
openclaw:mainfrom
chrischall:fix/606-docs-insert-default-end

Conversation

@chrischall
Copy link
Copy Markdown

Closes #606.

Summary

Iterative gog docs insert calls without an explicit --index previously stacked at position 1, producing reversed output (each new insert pushed earlier inserts further right). The help even called this out — "Character index to insert at (1 = beginning)" — but it's not what anyone reading insert as the editor-style "add at the end" default expects, and it silently produces broken docs in the dominant agent use case (build a long doc in chunks across many tool calls).

Picks option (2) from the issue: when --index is omitted, resolve end-of-doc via the existing docsTargetEndIndexAndTabID / docsAppendIndex helpers (same path docs write --append uses) and insert there. Explicit --index N still works exactly as before and skips the extra GET.

Change

  • DocsInsertCmd.Index is now *int64 instead of int64 with default:"1" — so we can distinguish "omitted" from "set to 1".
  • Run() branches on c.Index == nil:
    • omitted → GET the doc, derive docsAppendIndex(endIndex), also resolves the tab in the same call
    • explicit → validate >= 1, use it directly, no GET
  • Dry-run payload reports "atIndex": "end" when omitted, the explicit int otherwise. The text/JSON success output always reports the resolved integer index.
  • Help text updated: Defaults to end-of-doc when omitted.

Tests

  • TestDocsInsertCmd_DefaultsToEndOfDoc — asserts the GET runs once and the resulting InsertText.Location.Index matches endIndex - 1.
  • TestDocsInsertCmd_ExplicitIndexSkipsGet — asserts no GET when --index is supplied.
  • TestDocsInsertCmd_ExplicitIndexBelowOneRejected — preserves the existing >= 1 guard.

Existing TestDocsEditingCommands_WithTab (which exercises --index 5 --tab Second) still passes.

go test ./internal/cmd/ -count=1 → ok 23.8s.

Compatibility note

This changes default behaviour for callers that previously relied on the implicit --index=1. Per the issue's analysis, those callers were getting reversed output rather than something useful; the new default matches docs write --append and what insert means in any text editor. Anyone explicitly passing --index=1 is unaffected.

chrischall and others added 2 commits May 19, 2026 19:50
Closes openclaw#606.

Iterative inserts without an explicit --index previously stacked at
position 1, producing reversed output (each new insert pushed the
previous one further right). This is surprising for anyone reading
"insert" as the editor-style "add at the end" default.

Change `--index` from a defaulted int64 (default 1) to a pointer; when
unset, the command now fetches the target body/tab and inserts at
docsAppendIndex(endIndex), matching the existing `docs write --append`
behaviour. Explicit `--index N` still works exactly as before and skips
the extra GET. `--index 0` still errors.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gog docs insert: default --index to end-of-doc (or rename / require it explicit)

1 participant