Open hkatzdev opened 2 years ago
so you mean kind of a generic mechanism to say "this region is a link" providing maybe a popup and probably using #2474? lemme take a look at that escape.
hrmmm that list of software implementing it is pretty sparse
so you mean kind of a generic mechanism to say "this region is a link" providing maybe a popup and probably using #2474? lemme take a look at that escape.
I missed that issue, seems to be pretty similar. However, this will work for any text you want as a link, not just urls. It seems like that is more concerned with changing the mouse pointer when it is a link rather than telling the terminal something is a link though I may be wrong. > hrmmm that list of software implementing it is pretty sparse
The list hasn't been updated for nearly two years btw, some like Kitty and Konsole have had support merged since then.
The list hasn't been updated for nearly two years btw, some like Kitty and Konsole have had support merged since then.
argh!
so i agree this looks like an interesting capability.
how would we expose it to the user? would a certain bit of output be a link, or a certain plane? how does this integrate with the multiplanar model -- e.g. what happens if i emit a link, and then a plane gets created over the top of it, and i obliterate part of the text? does the entire link go away, does it apply to the left-hand-side, or does it apply to the two different sides? how do i kill the link once i'm done using it? this spec seems very much geared towards a use case where the link, once written, is never touched...
oh wait most of this is addressed, nevermind
alright, i think i could make this work, maybe, for some meanings of work. i think the right way to do this would be to manage it ourselves with a nclink
widget that acted on mouse inputs, but this could be a first approximation to that, and use the same API, thus getting the widget out more quickly.
an interesting counterpoint is that after our process has exited, we can't very well respond to mouse events involving our old output.
how does this integrate with the multiplanar model -- e.g. what happens if i emit a link, and then a plane gets created over the top of it, and i obliterate part of the text?
Would this be similar to dealing with multi-line hyperlinks? If so, you might find some inspiration from wezterm: https://github.com/wez/wezterm/issues/408
alright, i think i could make this work, maybe, for some meanings of work. i think the right way to do this would be to manage it ourselves with a
nclink
widget that acted on mouse inputs, but this could be a first approximation to that, and use the same API, thus getting the widget out more quickly.
I'm a bit confused about this comment. Wouldn't notcurses just emit the escape sequences for hyperlinks, and the terminal emulator would do all the user interaction. So notcurses wouldn't do any handling of mouse inputs for this itself.
For instance ls
has implemented support for hyperlinks. If you run ls --hyperlink=always
it will list the files as links and in a terminal emulator with support for hyperlinks you can click on them to open them.
Hi!
I think it would be pretty useful if there is a feature for easy hyperlink support and a simple fallback.
While some terminals automatically make urls into links, this escape sequence allows any text to be a link. Details on the hyperlink escape can be found at https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda.
Ideally, terminals not supporting it should have some sort of fallback to show both the text and url. It could be markdown style likeOn second thought probably just detecting support is better[example](https://example.com)
as long as it clearly shows the text and url. However, it is possible to just always use the escape sequence - the url is simply not shown.