Use per-thread color for the threading marker

[adrien-n]

Hi and thanks for matterhorn. :)

Whenever two threads are going on at the same time in a channel, I find it difficult to not mix them all the time. A fairly simple modification could be to change the color of the vertical marker for each thread.

I don't think it makes sense to optimize for > 8 threads at a time and more colors are probably not needed (you can have collisions, like you already have with nicks).

I'm not familiar with the codebase but I could imagine the following: whenever a thread is started, look at the color of the most recent thread and find the successor of that color in a list of colors. I think it would work well enough for me in practice. Of course more complex schemes are possible too but I'm not sure they're needed (I would be proven wrong at once when trying my simple approach in practice obviously).

Thanks!

[jtdaugherty]

Thanks for the suggestion!

look at the color of the most recent thread and find the successor of that color in a list of colors

It would be very easy for two threads that were started far apart in time to get assigned the same color. Once a conversation between people on those two threads starts to interleave, we'd end up with adjacent messages in the window with the same indicator color.

Rather than focus on this specific proposal, which I am not confident would be effective or simple to implement given what I know about the codebase, I'd rather focus on the problem you mentioned: that you find it easy to mix up threads. I'm curious, have you tried out the thread UI? (C-s -> t)

[xnox]

Other apps do not assign a permanent thread colour, but assign colours per current view. And add colours as more context comes in and/or as one scrolls. for example git log --oneline --graph --color

[adrien-n]

I've spent some time with the thread view and while it works well to read one thread, it doesn't help for my typical issue which is two threads active at the same time and interleaved. When two threads are active concurrently, the layout looks like the following:

user1: foo
| user2: foo foo
user3: bar
| user2: bar bar
user1: foo
| user4: foo foo baz baz
user3: bar
| user5: bar bar baz baz

In such situations, half of the lines are repeated and I tend to read repeatedly because a) it's not immediately obvious they're context and b) I need to know which thread the new messages are part of. That's where I think color could help. I don't really have other ideas besides coloring; it's a difficult topic.

[jtdaugherty]

Okay, thanks, @adrien-n. I'm not sure what else we could do to address that readability problem at the moment. I suspect that longer-term, the best option is to investigate supporting some of the new thread management features that the official client got a while back. I haven't had time to look into that to see how much of it could be sensible in a terminal context, though, so I can't say right now whether it's going to be possible. I'm going to close this in lieu of a new ticket on that feature so we have a reminder to investigate it. Thanks!