Way to get current dir on hyperlink_rules

[bentinata]

Problem

I want handle package.json:5:10 using VS Code, but find it hard to get current working dir on open-uri event handler.
https://code.visualstudio.com/docs/editor/command-line#_opening-vs-code-with-urls

Currently, I have to do tricks with wezterm.hostname() since pane:get_current_working_dir() return URI, while I just need current working dir without hostname and file: protocol.

config.hyperlink_rules = {
    {
        regex = [[[\w\/\.]+:\d+:\d+]],
        format = "vscode://file$PWD/$0",
    },
}

wezterm.on("open-uri", function(window, pane, uri)
    local start, match_end = uri:find("$PWD")
    if start then
        local cwd_uri = pane:get_current_working_dir()
        local start, match_end = cwd_uri:find(wezterm.hostname())
        local cwd = cwd_uri:sub(match_end + 1)
        uri = uri:gsub("$PWD", cwd)
        wezterm.open_with(uri)
        return false
    end
end)

Side question:
Why does wezterm.open_with(uri:gsub("$PWD", cwd)) doesn't works? Why do I need to reassign uri?

Suggestion 1: Add pane:get_current_working_dir_raw()

Or pane:get_current_working_dir_path().
Initially I was thinking about using os.getenv("PWD"),
but I feel like creating a new cross-platform pane method would be better.
I would need help on how current_dir works.
Doing quick search, I found this, but not sure where should I work on:

wezterm/term/src/terminalstate/mod.rs

Line 353 in 2516afa

current_dir: Option<Url>,

Suggestion 2: Add $PWD keywords on hyperlink_rules.format

Doesn't need to be $PWD.
Kinda feel like *magic*,
but simpler without modifying open-uri handler.
Same. Unsure where I should work on. Maybe here?

wezterm/termwiz/src/hyperlink.rs

Line 253 in 2516afa

fn expand(&self) -> String {

Thoughts? Thanks.

[wez]

First of all: I think what you're trying to do is flawed because it would mean that the behavior of hyperlinks already on screen may change when the cwd changes, which would violate the Principle of least astonishment.

The working directory is defined as a URL by the associated escape sequences. An application might set the CWD to be an FTP URL for example, or the hostname part of the file:// URL may be a remote host.
I won't make the API hide that fact.

Independent of whether trying to use the PWD in the click handler is a good idea or not: what I think would be good is to adjust the lua API to either return a URL object that in turn provides accessor properties to extract different portions of the URL, such as the file/path portion, or to provide a helper function that will parse a url and return such a helper object. The latter approach has no backwards compatibility concerns, so that is what I would suggest doing first.

[bentinata]

Thanks for the principle of least astonishment reminder. I was thinking that I am okay with it, since I rarely switch directory inside the terminal, and the error messages given by VS Code is pleasant enough in case I do switch directory.

But this makes me curious to see VS Code integrated terminal behavior, which what I'm trying to replicate.

$ pwd
/wezterm
$ echo Cargo.toml:7:4
Cargo.toml:7:4
$ cd ..

Clicking Cargo.toml:7:4 (or the variation, Cargo.toml:7, Cargo.toml, even ../wezterm/Cargo.toml) still works no matter my cwd, and doesn't violate the principle. Does it means VS Code integrated terminal parse every file-like output? Is it possible to replicate that? How would I implement it here?

Regarding the accessor properties, I think it's a better idea. Thanks.

[wez]

I don't use vscode and don't know how it works

[bentinata]

I mean, is it possible and acceptable to parse every filepath-like output in wezterm and turn each of it into explicit hyperlinks? Or is it something that is way out of the project vision (not sure how I should worded it?), since I don't see any API that can modify terminal output.

[wez]

re: $PWD in gsub, note that $ is listed as a magic character in https://www.lua.org/pil/20.2.html and needs to be quoted by prefixing it with a % escape character.

[wez]

re: Url type and escaping, please see:

• pane:get_current_working_dir returns url encoded text for non-ascii paths #4000

[bentinata]

Thanks. If you may, do you have some tips regarding wezterm development?
I tried these steps:

1. Making changes on lua-api-crates/mux/src/pane.rs
2. Creating a wezterm.lua at the root of the project containing:

local wezterm = require 'wezterm'

wezterm.on('window-focus-changed', function(window, pane)
  wezterm.log_info(pane:get_current_working_dir())

  wezterm.action.CloseCurrentPane { confirm = false }
end)

return {}

3. cargo run --bin wezterm -- --config-file wezterm.lua
4. See log on terminal

But it doesn't always apply my change. I need to do cargo build and then cargo run to see.

I then tried to make a smaller environment to just test mlua.
https://git.sr.ht/~bentinata/luacwd/tree/_/item/src/main.rs

[wez]

If you're changing the gui, you need to build and run wezterm-gui. wezterm spawns wezterm-gui, so just rebuilding wezterm is not sufficient for changes to be reflected in the gui process.

[wez]

I typically do:

$ cargo build
$ ./target/debug/wezterm --config-file ...