The space-segment patterns in the path regex (dotted_path_space_segments
and any_path_space_segments) greedily consume text after a space even
when we know that the text is the start of a new independent path (e.g.,
`/tmp/bar` in `/tmp/foo /tmp/bar`).
Fix: Add two negative lookaheads after the space in both patterns:
- `(?!\.{0,2}\/)` → don't match if the next segment starts with `/`,
`./`, or `../`
- `(?!~\/)` → don't match if the next segment starts with `~/`
Paths like `./.config/ghostty:` and `./Downloads:` were incorrectly
including the trailing colon. Add a `no_trailing_colon` lookbehind to
all path branches and prevent space segments from starting after a colon
so that `": text"` is not consumed as part of the path.
This
$10/bar.txt
was partially matching but should not match at all.
This commit fixes this by simply `[\w]` to `[A-Za-z_]` as the first
character of a bare relative path, so digit-starting fragments can't
match.
Another option would be a lookbehind but I think the check above is much
simpler.
A string like this
foo/$BAR/baz
should match fully, not partially.
This commit fixes this by expanding `\$[A-Za-z_]\w*\/` to
`(?:[\w][\w\-.]*\/)*\$[A-Za-z_]\w*\/` in rooted_or_relative_path_prefix
so that we optionally eat everything before a variable `$VAR/`.
Strings like
$10/$20
Should not match.
This commit fixes this by narrowing `\w` after `$` to `[A-Za-z_]` which
is— according to Google Gemini— what environment variables can start
with.
A string like
foo.local/share
should match fully, not partially.
This commit fixes this by moving `dotted_path_lookahead` before
`bare_relative_path_prefix` so the dot-check scans the entire match
rather than only the text after it.
Related to #1972
This commit adds three new alternatives for
`rooted_or_relative_path_prefix`:
- `~/`
- `$VAR` and
- `.local/`, `.config/` etc. for dot-prefixed directory names
Related to #1972
Fixes an issue when paths have embedded comma, e.g.:
shared/src/foo/SomeItem.m:12, shared/src/
with path_chars greedily consuming the rest of the string.
Now file path matching stops at comma. Scheme URLs are unchanged and
still using the comma.
Break up the big monolithic URL and path regex into named sub-pattern
constants and compose the final expression from three commented
branches:
- URLs with a scheme
- absolute or dot-relative paths
- bare relative paths
This commit only breaks up the regex. It keeps the existing matching
behavior unchanged.
Related to #1972
The URL regex for file path detection requires paths to start with
`../`, `./`, or `/`. For bare relative paths like
`"src/config/url.zig"`, the regex could only match starting at the first
`/`, producing `"/config/url.zig"` as a result — always dropping the
first part of the path.
Fix: added a third top-level alternative to the regex. This matches bare
relative paths where:
1. The first component is word characters (possibly with dots/dashes):
`[\w][\w\-.]*\/`
2. The remaining path must contain a dot (via positive lookahead) — this
requires a file extension to avoid false positives on text like
input/output
3. Add a `(?<!\w)\/` instead of `\/` in the existing prefix group — the
standalone `/` prefix now requires that `/` is not preceded by a word
character. This prevents `"input/output"` from falsely matching
`"/output"`
Test cases added:
- src/config/url.zig → matches fully
- app/folder/file.rb:1 → matches with line number
- modified: src/config/url.zig → matches only the path part
- lib/ghostty/terminal.zig:42:10 → matches with line:col
- some-pkg/src/file.txt more text → stops before trailing text
- input/output and foo/bar → correctly do not match (no file extension)
The issue was nailed down here:
https://github.com/ghostty-org/ghostty/issues/1972#issuecomment-3845717672
- Add IPv6 URL pattern matching to support URLs like http://[::]:8000/
- Separate IPv6 URL pattern from main regex for better maintainability
- Add extensive test cases covering:
- Basic IPv6 URLs with ports
- URLs with paths and query parameters
- Compressed IPv6 forms
- Link-local and multicast addresses
- Mixed scenarios and markdown contexts
To implement this I extended the existing regex variable in the `src/config` dir. In a few test cases, extra space is added intentionally to verify we don't include space in the URL as it looks & feels odd.
