Add support for hyperlinks in text (OSC8)

[lypanov]

An interesting specification to add hyperlinking support directly to terminal emulators has been created, see: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

I'd like to use this support in a small patch I'm creating for the application alot which uses urwid as it's TUI layer.

I've created a patch for URWID to add such functionality and would love feedback on it. I'll upload the patch to a PR as soon as I've cleaned it up enough for public eyes.

Would you be interested in such a patch?

[tonycpsu]

Certainly!

[lypanov]

Sorry delayed on this until I find the time to finish off my MR. My current branch is at: lypanov@a6351f6

It fills my need (I have working but weird looking links in alot) but right now it's both a mess and incomplete.

[danschwarz]

Any update on this? I see your code and the ansi widget where you've implemented the feature.

I tried to implement this for the Toot Mastodon client, and in my first pass I took a different approach; I have a wrapper that can surround text with an OCS 8 escape sequence and turn it into a clickable hyperlink. This is OK for a standalone link, but insufficient for rendering a hyperlink within a block of ordinary text.

It'd be ideal to have a new Text widget that includes support for embedding hyperlinks with the OCS 8 sequence. I've tried several different approaches to modify the Text widget and add that feature. Haven't found an elegant way to implement it, yet.

[lypanov]

Sorry for the lack of feedback here. Once my RSI has calmed down I'm hoping to resurrect my merge request which I assume conflicts horribly with the latest version of urwid. I'm unsure what the best approach is alas. The approach I took in the patch set was the most pragmatic route to getting it working for my specific use case. I'm happy there seems to be more interest in OSC 8 at least. I chose Ansi Widget purely because this was the route that alot took for some complex rendering and I based my work upon that. I'll check the status of that work also.

[danschwarz]

There's a nice solution in the Urwidgets project by @AnonymouX47 , a Hyperlink widget plus a TextEmbed widget. I've been working with it.

[AnonymouX47]

My Proposition:

Add a class like

class LinkAttrSpec(uri: str, attr: LinkAttrSpec | Attrspec | str | None = None):
    """Hyperlink display attribute specification.

    Args:
        - uri: The URI to which the text links.
        - attr: A display attribute.

          If a `LinkAttrSpec`, its underlying non-hyperlink display attribute is used instead.
    """

that should be used just like AttrSpec i.e as a display attribute.

This new class will be handled in

urwid/urwid/display/_raw_display_base.py

Line 549 in d7eb3ce

def attr_to_escape(a: AttrSpec | str | None) -> str:

and possibly a method analogous to

urwid/urwid/display/_raw_display_base.py

Line 779 in d7eb3ce

def _attrspec_to_escape(self, a: AttrSpec) -> str:

would also be added.

I'm not yet sure whether or not attr=None should be treated the same as with normal text runs with None as display attribute i.e whether or not Text(("bold", (LinkAttrSpec(uri), text))) should be equivalent to Text((LinkAttrSpec(uri, "bold"), text)), and also via AttrMap, etc... but if it will, it'll require creating special cases for LinkAttrSpec in a couple of places which might not be so easy to spot.

Why not extend AttrSpec?

In one word, convenience.

In full,

1. The user doesn't have to specify fg and bg (which are required by AttrSpec) every time they're creating a link attribute.
2. The extra (non-hyperlink) display attributes can be specified as usual i.e as a string (palette entry), AttrSpec or None.
3. This approach faces the same problem with "overlapping" display attributes as described above but is much more difficult to solve since an Attrspec can't be easily combined with another attribute specification.

... amongst others.

---

Thank you. 😃

What do you all think?