a Look path can name a range, and search selects what it found

file:LINE:COL-ENDLINE:ENDCOL, with the two short forms people actually type
reading naturally: file:412:9-21 on one line, file:412-418 whole ones. Ends are
inclusive. A path feature, not a search feature — a ranged path typed in a tag
or middle-clicked out of a shell's output selects just the same; search is only
its first consumer.

The dash is the fussy part. `-` was already a file char, so a ranged word
survives click expansion whole, but a range needs a number on BOTH sides or
my-file:10, build-2 and 2026-07-30 would stop being paths. Table-driven test in
look.zig for exactly that.

Selecting goes through the cellRange/setPaneRange pair the multi-cursor work
left, and hxOff clamps both ends, so a stale range selects what still exists
rather than crashing or reaching past EOF — pinned with an 8:6-400:9 range in a
nine-line file.

Producers: / search, Grep, and five LSP sites through a new spanRow — goto,
references, rename tokens and both symbol lists were throwing away real
protocol ranges at path:line:col. Left alone deliberately: Find rows are bare
paths with nothing to span, a jump is a spot not a span, and the diagnostic and
format paths only ever have a point, where half a range would be worse than
none.

One knock-on worth knowing: n now leaves an EXPLICIT selection, so a topbar
execute chords it. grep.snap's no-match step was silently becoming
`Grep TARGET`; it runs from the leader path now, which never chords, and the
dedicated chord steps stayed where they were.

1 files changed, 21 insertions, 0 deletions

diff --git a/src/config.zig b/src/config.zig
index 8f2175f6..2603a40c 100644
--- a/src/config.zig
+++ b/src/config.zig
@@ -430,6 +430,27 @@ pub fn wordBounds(line: []const u8, col: usize) struct { lo: usize, hi: usize }
 /// place.
 pub const line_col_sep: u8 = ':';
 
+/// ...and separates that spot from the END of a RANGE. A look at a ranged path
+/// SELECTS the span rather than just parking on its first cell, which is what
+/// lets a search result carry the text it matched and `n` land ON it.
+///
+/// Three spellings. The long one subsumes the other two, but the short ones
+/// are what a person actually types and what a grep-alike emits, so all three
+/// parse:
+///     main.zig:412-418        lines 412 through 418, whole
+///     main.zig:412:9-21       line 412, columns 9 through 21
+///     main.zig:412:9-418:1    line 412 column 9 through line 418 column 1
+/// Both ends are INCLUSIVE and 1-based, like the spot they extend — `412-418`
+/// reads as seven lines, not six. `main.zig:412` and `main.zig:412:9` keep
+/// meaning exactly what they always did.
+///
+/// Must be an isFileChar member, same as the separator above, or a click would
+/// expand to half a range. That is also why reading it is FUSSY (look.zig,
+/// parsePathLine): ordinary paths are full of dashes, so the suffix counts as
+/// a range only when a NUMBER follows the dash — `my-file:10` and `build-2`
+/// stay the paths they are.
+pub const range_sep: u8 = '-';
+
 /// `@p7:10:5` — pane 7, line 10, column 5. The one look target that names a
 /// live pane instead of a path, because terminals and output buffers have no
 /// file for a location to point at. Both the writer (a `/` result row) and the