link-url not working for links in weechat

[apetresc]

Links are detected and work fine if they're just simply output to stdout through echo or cat or something. But in a complex TUI application like weechat, none of the links seem to be getting picked up. Here's an example:

None of the various links present in this screenshot (there are several) do anything when ctrl-clicked (they don't open, nor are they underlined). However, if I copy and paste them into an "echo", they work fine.

Note that none of the links here are split across multiple lines; I understand why that wouldn't work (although my understanding is that there is some magic you could theoretically do to have that work as well). But even in this simple case where they're all in one unbroken line, ghostty doesn't seem to pick them up. Alacritty does handle it.

(If it matters, this is on Linux, GTK backend, on i3).

PS: Loving ghostty overall so far! Daily driving it since the public release :)

[joshbode]

This may be unrelated, but I noticed today that when I use tmux, I have to use Control-Shift (actually, Command-Shift since I'm on a Mac) to trigger URL matching, rather than just Control. Without tmux it works with just Control (Command), though.
I think this behaviour changed between 1.0 and 1.0.1

[douglascamata]

Makes total sense, @joshbode. When I disabled the mouse capture events in lazygit the behavior was exactly as in 1.0.0.

[HartBlanc]

None of the values for mouse-shift-capture enable me to click a link using Command without shift in tmux

[joshbode]

Makes total sense, @joshbode. When I disabled the mouse capture events in lazygit the behavior was exactly as in 1.0.0.

Similarly, in tmux if I disable the mouse (set-option -g mouse off) then I can select links with only Command, but it's definitely not an option I want to disable. Command-Shift is fine, though.

[HartBlanc]

I suspect this PR has introduced this change in behaviour - it seems to be associated with mouse reporting being enabled (which would explain it being sensitive to set-option -g mouse off)

3903

[rockorager]

I responded on the PR but will copy my thoughts here:

I tested a couple terminals before deciding on this behavior, but I don't have
any on my system that have a behavior I like (except for foot, with it's hints -
but this is entirely different). The closest in features is kitty, which has
hover action without pressing anything. Having used this for a few days now, I
would agree that it would be nicer to have the functionality be the same whether
capture is on or not, especially since there isn't an obvious way for the user
to know if the application has mouse events on.

@mitchellh I think it's worth changing this, what do you think?