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/config.zig | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'src/config.zig') 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 -- cgit v1.3