Issues with link IDs and style caching

[rodrigogiraoserrao]

This is an account of many small related issues (not necessarily bugs, per se) uncovered while working on Textualize/textual#1587

• Hashing doesn't take into account the link ID, so styles that look the same but have different link IDs will clash.

• Style._link_id is created inconsistently: the attribute _link_id is created in a couple of different places and is created inconsistently across those locations.

Some examples

rich/rich/style.py

Lines 192 to 194 in 6d30ad0

	self._link_id = (
	f"{randint(0, 999999)}{hash(self._meta)}" if (link or meta) else ""
	)

rich/rich/style.py

Line 243 in 6d30ad0

style._link_id = f"{randint(0, 999999)}{hash(style._meta)}"

rich/rich/style.py

Line 688 in 6d30ad0

style._link_id = f"{randint(0, 999999)}" if link else ""

• Style addition is cached in Style._add and the dunder method __add__ only refreshes the link (by using .copy on the result) if the result has a .link, but it doesn't check for .meta.

• The method Text.render adds another layer of caching that bypasses the link refresh because of hashing clashes (maybe using the style indices instead of the styles themselves as cache keys fixes this).

I couldn't make much progress in solving these issues because I don't quite understand the semantics of the attribute .link_id. Is it supposed to be a different ID for any Style instance that contains a link or some meta data?
Then, why not use the object ID itself?

@property
def link_id(self):
    return str(id(self)) if self.link or self.meta else ""

[github-actions]

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

This is an automated reply, generated by FAQtory

[willmcgugan]

The _link_id is a unique id used when generating terminal links. It's sole purpose is to let the terminal know what to highlight when you hover over it.