Allow custom URL handlers

[pluiedev]

Successor to #4379.

Currently we open all URLs via the system's builtin URL handler (xdg-open on Linux/BSDs, open on macOS), but that might not be always desirable. In particular there's a strong case to be made, to allow terminal text editors to handle file links inside the terminal, without needing to open a separate window.

---

I am personally in favor of this proposal as opening a wholly separate terminal window just for viewing or editing a file seems overkill, and may not work properly on Linux because of how a "default terminal" is a non-concept there. I'm less certain as to how we should implement this, but that's what this discussion is for.

[joshbode]

Currently we open all URLs via the system's builtin URL handler (xdg-open on Linux/BSDs, open on macOS)

This is not necessarily something we need to deal with here, but I don't think this is true on macOS any longer - as far as I'm aware, OSC8 URLs are now opened via NSWorkspace API (see #7843).

This change had a few side-effects that make handling parameters like line/column numbers difficult since macOS can't/won't handle file URLs like file://{host}{path}:{line}:{col} (a common representation) since the OS will consider the file to not exist, and while strategies like file://{host}{path}#line={line};char={col} (see RFC5147) pass through the OS, the parameters are unfortunately stripped by macOS.

[llimllib]

A survey of prior art:

• Kitty calls these open actions, you configure matchers and connect them to actions
• Wezterm gives you lua config, you write lua code similar-ish to neovim config
• I think that Alacritty reuses hints to handle this
• iterm2 uses Semantic history which defaults to similar behavior as ghostty, but allows you to choose to run a process
  • Unless I'm missing something, this is very inflexible and you can't do anything like "run the image editor if I click an image" without resorting to custom scripting

[joshbode]

In my implementation, the patterns might match URLs, but they could really match anything - in fact, I use it to map Linear and JIRA ticket IDs to their canonical URL so that selecting them takes you to their page.

[llimllib]

If you want to use mime-types why not just let the system handler do this?

I think the system handler can only launch a process in response to a file, which makes it really hard to open a program in the current terminal. it's convoluted to imagine a chain like:

$ ls -> 
    click on `index.zig` -> 
    ghostty launches `open` or `xdg-open` ->
    user has configured `open` for `zig` types to be a custom script that somehow finds the original terminal window and launches `nvim` with index.zig in it

versus:

$ ls ->
    click on `index.zig` ->
    ghostty checks to see if the user has a `text/zig` handler ->
    ghostty opens nvim with `index.zig`

For me, the key element here is to allow a user to click on a file and have it open in the terminal editor of their choice in the same terminal as they clicked it. It works in kitty and it's wonderful, I use it hundreds of times a day

[nesqi]

You are right, that is also a concern.
I still don't understand how ghostty would determine what mime-type a URL is. If it's only going to look at file extensions like Kitty I still think a regex would be easier to implement and more useful.

[joshbode]

In my usage, I dodge that chain by opening Neovim in a terminal (actually in a tmux pane) and then use a script to open files in it remotely.

so for me, it looks more like:

$ ls ->
    click on `index.zig` ->
    ghostty execs my script with the string `index.zig` ->
    my script sends nvim a remote command to open `index.zig`

[pluiedev]

Ideally though that this will work without any custom scripting or remote control whatsoever, given that Ghostty is already able to parse, sort and handle URLs based on e.g. URL scheme and file types and we can dispatch actions based on that whenever the user opens a URL