Why are all the messages in "reverse" order?

[brunobord]

Hello. And first of all, thank you for this very nice litte tool, really interesting.

I was a bit puzzled by the order of the ordering of the messages, that are stacked upon each other, from the newest to the oldest, while it looks more familiar and more readable to have them the other way around. When you read from top to bottom, you expect the question before the answer, for example, or the event announcing that someone is connected before their firs message, etc.

Would it be possible to reverse the order of the messages, or, even better, to have an optional parameter to make your choice if you prefer the top-down or bottom-up display?

[lemunozm]

Hi @brunobord,

My first try was to make it as you say: from top to the bottom, but I found a limitation in tui-rs (the library used to draw in the terminal). If you write in down direction, you need to take some things into account: first, the new message must be placed in a row that you initially do not know, it depends on the previous messages on the top, but if the previous message fills the entire viewport you need to write in the fixed position: the bottom line of that viewport. Until here, more or less easy. The problem comes when a message can take several lines based on its length. tui-rs offers the ability to display a message in several lines using an internal algorithm, but it is computed when you render the own message. So, in order to know where is the position where I need to render the message I need to render the message first to know its length in the viewport. Something like a paradox. To add more complexity, a message could contain unicode characters that varying the length of the renderered message, so tries to preanalyze the message becomes really difficult. Place the message in reverse order solves all these problems. It is a pity 😢 .

Anyway, I tried this several months ago, and I do not know if tui-rs offers now a new utility to solve this problem. Obviously, if somebody makes a PR with this change will be more than welcome! 😃

[brunobord]

oh. that sounds very tricky :/ unfortunately, I don't know Rust, so I won't be able to help :( thank you for the explanation, though.

[lemunozm]

There is a related issue in tui-rs talking about the same problem (different perspective, but same problem): https://github.com/fdehau/tui-rs/issues/89

[v1nam]

Maybe you can manually split the user input it if its longer than the screen width, and make a variable to track the total number of lines that message is going to take, and by doing this for all the messages and adding them to the variable, you can get an offset by subtracting the message panel height by this length if the length is greater, and use that offset for the scroll method in the paragraph widget, might work :thinking:

[lemunozm]

and make a variable to track the total number of lines that message is going to take

I think that the main problem resides here. How do you know to split a message (or a paragraph) into lines? It could contain Unicode characters that can be represented with different widths and depending on if the last word fits in the line it could be moved to the following line. To be sure you split all possible messages correctly, you need to "replicate" exactly the internal algorithm that tui uses to render a paragraph into lines :(

[v1nam]

Oh, fair enough

[janjaapbos]

Actually, my preferences would be the current implementation, the newest on top ;-)