too much whitespace before right-aligned nicks?

[dei-layborer]

I'm not sure if this is a bug or a feature request exactly, so I'll leave y'all to be the judge :)

From a visual standpoint, the one thing that I find Halloy to be missing is in how nicknames are displayed. Specifically, the "column" where nicknames are (to the left of the messages themselves) is difficult to size properly.

Currently, if alignment is set to "right" and no truncate value is set, the "column" for the nicknames ends up way too wide, with tons of empty space between the timestamp and the actual nickname. In the alternative, if a value is set, there's still too much whitespace between the left of the nick and the timestamp for those nicks that are right at the "truncate" value. Moreover, if truncate is set, this doesn't shrink the amount of space taken up by the nicknames "column" and so results in more whitespace between the timestamp and the start of the nick.

What would be ideal IMO is where if nicks are right-aligned, the "column" for the nicks would be just wider than the longest nick that is visible. This is how WeeChat does it (see screenshot), for example.

Hopefully this all makes sense, but please let me know if e.g. screenshots would be helpful.

[andymandias]

The column size does shrink based on the truncation. A quick test with truncate = 2 shows the timestamp as the limiting width.

Maybe a screenshot would help me understand? It is maybe worth noting that variable-width fonts are not currently supported.

[andymandias]

We could add a setting to hide the end of the timestamp range for condensed messages.

[furudean]

would it make sense to use the widest nick of someone who actually is visible in the current buffer as opposed to the longest name in the nicklist?

+1 on shrinking the timestamp range for condensed messages

[dei-layborer]

Weird, that's not what I'm getting at all. All the shots below are with alignment = "right".

Here's what happens if nothing is set for truncate:

Here's with truncate = 10:

And here's with truncate = 2:

The reddish nick there is the same in all three screenshots, and is 10 characters long (not counting an @ due to mod status and < > from brackets).

[dei-layborer]

would it make sense to use the widest nick of someone who actually is visible in the current buffer as opposed to the longest name in the nicklist?

+1 on shrinking the timestamp range for condensed messages

This is what I was getting at (using the widest nick that's actually visible).

[darienm]

If adjustments to the text widths are being considered for this "bug" labeled issue, perhaps they could be expanded ever so slightly to accommodate the "feature" labeled issue #945 which also is a result of undesired whitespace.

[andymandias]

The width used is the maximum nickname length in the history. That could certainly be narrowed down to some form of "recent history".

I want to make sure I'm understanding your screenshots correctly, you're seeing more whitespace with truncate = 2 than with truncate = 10? And it looks like more whitespace with truncate = 2 than with truncate not set?

[dei-layborer]

The width used is the maximum nickname length in the history. That could certainly be narrowed down to some form of "recent history".

I want to make sure I'm understanding your screenshots correctly, you're seeing more whitespace with truncate = 2 than with truncate = 10? And it looks like more whitespace with truncate = 2 than with truncate not set?

Correct. One thing I noticed is that when going from truncate = 10 to truncate = 2 by reloading the config file, the width of the message parts doesn't change, which might explain some of this.

I'll add that I'm on Linux (openSUSE tumbleweed), and am still on version 2026.4 since my distro hasn't updated it yet.

[andymandias]

Ah, the logic used in laying out the message view was significantly restructured between the two versions. If you can test with 2026.5 when able and report if you're still seeing the behavior, that would be appreciated.