From 911215846f1d5a9b2e37a00e74fb9266d4a0884a Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Fri, 31 Jul 2026 11:42:18 -0300 Subject: a Look path can name a range, and search selects what it found MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- src/tutor.txt | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'src/tutor.txt') diff --git a/src/tutor.txt b/src/tutor.txt index 2d0e951a..ee6f9f79 100644 --- a/src/tutor.txt +++ b/src/tutor.txt @@ -166,11 +166,16 @@ pane's directory searches for it — acme's button 3 — except in tty mode, where the click belongs to the program on the other end. On a shell with no search armed, n/N instead step the lookable tokens in its output. - A hit in a file reads `path:LINE:COL`, the ordinary look target. A hit in - a shell or an output buffer has no file to name, so it reads `@pN:LINE:COL` - — pane N, line LINE, column COL. Looking either one goes there; the column - is optional (`main.zig:100`, `@p3:12`) and you can type one yourself - anywhere text lives. + A hit in a file reads `path:LINE:COL-ENDCOL`, the ordinary look target + carrying the SPAN that matched. A hit in a shell or an output buffer has no + file to name, so it reads `@pN:LINE:COL-ENDCOL` — pane N, then the place in + it. Looking either one goes there and SELECTS the span, which is why n/N + land ON a hit rather than beside it. + The range is part of the PATH syntax and not part of search: type one + anywhere text lives and a look on it selects. `main.zig:412-418` is whole + lines, `main.zig:412:9-21` is columns on one line, `main.zig:412:9-418:1` + is the general form, and the shorter spellings still mean what they always + did — `main.zig:100`, `main.zig:100:7`, `@p3:12`, all of them optional. FIND: the "Find" builtin (SPC f f) arms the same tag input, but Enter walks the pane's DIRECTORY instead of its text — `fd`, in-core — and writes one matching PATH per row into the same "+Search" buffer. Rows are look -- cgit v1.3