Make it easy to use long URLs from chat

[gavinbeatty]

Is your feature request related to a problem? Please describe.
When a long URL is posted by others in chat, it is often split across multiple lines in twitch-tui. Because of the border and the way chat messages are shifted into their own column, this splits the URL into pieces and includes border characters (on the right and left). Using windows-terminal, I cannot CTRL+click the link as it will be missing many components because of the split (especially given the including of border characters). I can select the text and copy, including these irrelevant characters, but must strip them manually before actually using the URL.

Describe the solution you'd like
Keyboard combo (CTRL+P let's say) which re-renders with no borders, and where chat messages that overflow to the next line use the full width on the new line(s). Then windows-terminal (and many other terminals) would correctly recognize the full URL and allow me to simply CTRL+click on it to open it in a browser. All messages in the buffer that fit in the window would be re-rendered. Pressing the combo again would render normally again (borders, right aligned messages).

Looking only at a single message for simplicity's sake:

│09:16:01     theusername Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor    │
│                         incididunt ut labore et dolore magna aliqua.                                      │

Could be re-rendered like this:

09:16:01     theusername Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua.

Another made up example of what I get when I select and copy to clipboard: https://a.really.long.dns.name ││ /a/really/long/path/component

And the corresponding URL that was actually posted, that I can recreate by removing irrelevant characters: https://a.really.long.dns.name/a/really/long/path/component

Describe alternatives you've considered

1. Option in config for borderless
2. Option in config for allowing chat messages to use the full width when it overflows

This would be slightly less visually appealing, but I would be far more functional, so I would use this config at all times.

Additional context
None.

[Xithrius]

Yeah, this has been problem for quite a while, and has been tracked in #260 and #262. The problem with wrapping is that we can't easily overflow into the next row. Currently, the widget displaying messages is a table, so we'd have to do some wack stuff with somehow chunking the message between columns to get it to work. That wouldn't fully solve the problem, due to there being a space as a separator between columns.

I was thinking that it might be possible to parse out the link of a message with the url crate and then have a keybind to select said link, but I'll have to see how that goes. Otherwise, I'll still implement the boarderless feature that you've suggested. Unfortunately, full width may not be possible at this time.

Thanks!

[gavinbeatty]

I see, can the re-rendered view instead be a list or a table with only one column? Even if it means the (timestamp, username, message) fields are no longer justified, it would still work quite well I think. Maybe then it can be thought of a "justified" mode (defaults to true) and CTRL+J flips it off and on.

[Xithrius]

It's possible, but there are features that rely on the table having separated columns, such as searching. Perhaps I can make a custom table widget so wrapping can have a full row in 3 columns.

[Xithrius]

I take that back. I should probably rewrite the table to a list with attributes that can be searched beforehand. Will take me a bit, but it's about time that I do it. The table doesn't look similar enough to regular Twitch chat.

[gavinbeatty]

That sounds like it would be nice. Not sure I fully understand the specifics of what you mean about searching attributes beforehand, but I don't quite know how things work right now anyway, so that's no surprise :)

I'd especially like it if it means there is a search that operates on usernames. In fact, if search always operated on both (username, message) at once, that would be great. Half the time I want to use search, it's motivated by "what has user123 said", and the other half is your usual "find times people wrote wordxyz in chat". Separate search operations for each field would work too, of course.

I'm not trying to sneak in another feature request inside this one, but your attributes searching comment sounded vaguely similar, so I bring it up.

[Xithrius]

Nah I'll definitely implement that, I like the sound of it :)

[Xithrius]

Progress is being made on the https://github.com/Xithrius/twitch-tui/tree/chat-to-list branch.

[Xithrius]

Sorry for the long wait, but I've ran into a bunch of issues implementing this, so it may be a bit longer before a working version is released.

[gavinbeatty]

This is the only twitch client I know of that works, and doesn't use hundreds of megs of memory. I'm grateful for what's already provided. So no worries about it.

[Xithrius]

A little progress update. Here's an example of what the chat window now looks like:

Even though it looks decent at the moment, there's a ton of problems that come along with this implementation as of now.

For one, there are random duplicate characters that appear below once a message is sent. I'm unsure what's causing this, but a possible solution is just to have every message be padded with whitespace on the right. Here's an example of the artifacts:

The boarders around the chat window sometimes break along with the artifacts, but padding with whitespace might be the solution to everything here.

Lastly, searching is very broken at the moment. I mean, very broken. Here's a screenshot from a couple weeks ago:

I hope to fix these problems in the coming days or weeks.

[Xithrius]

Progress can be tracked even further in #301

[Xithrius]

I somehow made a ton of progress in one night and now searching is almost fully working, with no artifacts in sight.

[gavinbeatty]

An artifacts issue (similar, maybe identical, maybe not) exists in the version I’ve been using (a few months old) so it’s not just the new view. Just FYI. I believe it even happens without sending a message, but I’m not sure, so don’t pull your hair out looking for another issue, it may be a red herring. I’ll file something next time I see a useful example of it.

[Xithrius]

I have a feeling the artifacts have something to do with crossterm, but that's an issue for another time.

[gavinbeatty]

I always had a feeling it had something to do with compound emojis. My memory is hazy, but I think I saw the male sign, ♂, as an artifact a few times, and that's mostly used as a modifier in a compound emoji. There may be fundamental problems with windows-terminal here as well. Just another anecdote for you.

[Xithrius]

It might be null bytes, unsure.

[Xithrius]

If there are null bytes, I've made changes so they're removed from the messages. Will be in the next release.

On another note, searching seems to work, along with username highlighting. I just need to fix a crash and everything should be good to go.

[gavinbeatty]

Sounds good. Then once the border is optional, the terminal should have a chance of being able to interact with URLs normally (e.g., ctrl+click).

[gavinbeatty]

Observed the artifacts (on an old version).

As it appeared on twitch.tv in Firefox:

9:45
chatguessr
: :earth_americas:
Round 2 has finished. Congrats 🇬🇼 bAD_aT_gEOgUESSR !

How it appeared in twt.exe in windows-terminal:

│09:45:55  🔨     chatguessr ACTION 🌎 Round 2 has finished. Congrats 🇬🇼AD_aT_gEOgUESSR !                                  │
│09:46:01        💎⭐Absim11 ohhh Germany 2 i get it                    🇼                                                    │

Note that the Guinea-Bissau flag (after "Congrats") is composed of G and W regional indicator symbol letter emojis.

Problems:

1. the lowercase "b" after the flag is missing in the twitch-tui version.
2. the latter half of the compound Ginnea-Bissau flag emoji is present in subsequent lines as an artifact (at the same x coordinate as it appears in the original message).

The 🇼 appears on all subsequent lines until a message that is long enough to "overwrite" it.

Also, scrolling with the mouse wheel leaves all extraneous 🇼 fixed in place. So if you consider the (fixed size) terminal window as a grid with (0,0) x,y-coordinate at the top left, then if 🇼 appears at (20,10), (20,11), (20,12), etc., If I scroll up, you would expect the y-coordinate to increase for all messages (they go down the screen) to (20,11), (20,12), (20,13). And they do, except the 🇼 which stay at their original coordinates, (20,10), (20,11), (20,12).

[Xithrius]

Very interesting. Thank you for reproducing! Hopefully this'll be fixed by the next release.

[ModProg]

Not sure if this might already be a implemented, but there is OSC8 which might help in supported terminals.

(I just noticed that I already created an issue quite some time ago :D #260)

[Xithrius]

Thanks, I'll take a look at that.