fix: remove "block" from hunk keywords to avoid false positives

Author: umputun

.claude-plugin/skills/revdiff/references/usage.md

@@ -152,6 +152,6 @@ don't remove this validation
 
 Each annotation block: `## filename:line (type)` where type is `(+)` added, `(-)` removed, or `(file-level)`.
 
-When annotation text contains keywords "hunk" or "block" (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., `handler.go:43-67 (+)` instead of `handler.go:43 (+)`). This gives AI consumers the range context without any extra steps.
+When annotation text contains the keyword "hunk" (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., `handler.go:43-67 (+)` instead of `handler.go:43 (+)`). This gives AI consumers the range context without any extra steps.
 
 Use `--output` / `-o` flag to write annotations to a file instead of stdout.

CLAUDE.md

@@ -17,7 +17,7 @@ TUI for reviewing diffs, files, and documents with inline annotations, built wit
 - `highlight/` - chroma-based syntax highlighting, foreground-only ANSI output
 - `keymap/` - user-configurable keybindings (`Action` constants, `Keymap` type, parser, defaults, dump)
 - `theme/` - color theme system: Parse (with hex validation), Load, List, Dump, InitBundled, BundledNames, ColorKeys (bundled: dracula, nord, solarized-dark)
-- `annotation/` - in-memory annotation store, structured output formatting; `Annotation.EndLine` enables hunk range headers when comment contains "hunk"/"block" keywords
+- `annotation/` - in-memory annotation store, structured output formatting; `Annotation.EndLine` enables hunk range headers when comment contains "hunk" keyword
 - `ui/mocks/` - moq-generated mocks (never edit manually)
 
 ## Key Interfaces (consumer-side, in `ui/`)

README.md

@@ -506,7 +506,7 @@ refactor this hunk to reduce nesting
 don't remove this validation
 ```
 
-When annotation text contains keywords "hunk" or "block" (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., `handler.go:43-67 (+)` instead of `handler.go:43 (+)`). This gives AI consumers the range context without any extra steps.
+When annotation text contains the keyword "hunk" (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., `handler.go:43-67 (+)` instead of `handler.go:43 (+)`). This gives AI consumers the range context without any extra steps.
 
 ## Contributing
 

site/docs.html

@@ -437,7 +437,7 @@ <h2 id="output-format">Output format</h2>
 <span class="code-comment">## store.go:18 (-)</span>
 don't remove this validation</code></div>
         <p>Each annotation block: <code>## filename:line (type)</code> where type is <code>(+)</code> added, <code>(-)</code> removed, or <code>(file-level)</code>.</p>
-        <p>When annotation text contains keywords &ldquo;hunk&rdquo; or &ldquo;block&rdquo; (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., <code>handler.go:43-67 (+)</code> instead of <code>handler.go:43 (+)</code>). This gives AI consumers the range context without any extra steps.</p>
+        <p>When annotation text contains the keyword &ldquo;hunk&rdquo; (case-insensitive, whole word), the output header automatically expands to include the full hunk line range (e.g., <code>handler.go:43-67 (+)</code> instead of <code>handler.go:43 (+)</code>). This gives AI consumers the range context without any extra steps.</p>
 
         <h2 id="integration">Integration with other tools</h2>
         <p>The structured stdout output works with any tool that can read text:</p>

ui/annotate.go

@@ -12,8 +12,9 @@ import (
 	"github.com/umputun/revdiff/diff"
 )
 
-// hunkKeywordRe matches whole-word "hunk" or "block" (case-insensitive).
-var hunkKeywordRe = regexp.MustCompile(`(?i)\b(hunk|block)\b`)
+// hunkKeywordRe matches whole-word "hunk" (case-insensitive).
+// "block" was removed as it triggers false positives in casual usage (e.g., "this code block is fine").
+var hunkKeywordRe = regexp.MustCompile(`(?i)\bhunk\b`)
 
 // newAnnotationInput creates and focuses a text input for annotation editing.
 // prefixWidth accounts for the visible prefix characters (cursor col + emoji + label + margin).

ui/model_test.go

@@ -963,20 +963,20 @@ func TestModel_AnnotateHunkKeywordSetsEndLine(t *testing.T) {
 		assert.Equal(t, 3, anns[0].EndLine, "EndLine should be last add line's NewNum")
 	})
 
-	t.Run("block keyword on single remove in mixed hunk", func(t *testing.T) {
+	t.Run("block is not a hunk keyword", func(t *testing.T) {
 		m := testModel([]string{"a.go"}, nil)
 		m.tree = newFileTree([]string{"a.go"})
 		m.focus = paneDiff
 		m.currFile = "a.go"
 		m.diffLines = lines
-		m.diffCursor = 1 // on "old line" (remove, OldNum=2) — only one remove in this hunk
+		m.diffCursor = 1 // on "old line" (remove, OldNum=2)
 		m.startAnnotation()
 		m.annotateInput.SetValue("review this BLOCK carefully")
 		m.saveAnnotation()
 		anns := m.store.Get("a.go")
 		require.Len(t, anns, 1)
 		assert.Equal(t, 2, anns[0].Line)
-		assert.Equal(t, 0, anns[0].EndLine, "single remove line, no multi-line range")
+		assert.Equal(t, 0, anns[0].EndLine, "block is not a hunk keyword, no range expansion")
 	})
 
 	t.Run("no keyword does not set EndLine", func(t *testing.T) {