On 23. 5. 26 11:38, Ivan Zhakov wrote:
On Sat, 23 May 2026 at 10:21, Branko Čibej <[email protected]> wrote:
[..]
I'd also suggest these two functions be renamed to ..._trim_left()
and ..._trim_right(), because that's what they actually do. I'd
let the caller deal with padding, either via *printf() or in any
other way they like, and have the trim functions return the (byte)
length of the transformed strings as well as their visual width.
Another option that comes to mind would be to add TRUNCATE argument
and keep align_left()/align_right() function names. In this case it
will be clear if function truncates existing string and also can be
used in situation when truncating is not needed.
The catch as I see it is that align-{left,right} and trim-{left,right}
are independent operations. For example, in the 'svn blame' output that
stared this discussion, we align to the right and also trim on the
right, whereas ..._align_right() trims on the left. All four align/trim
combinations are possible. So if you just add a TRUNCATE flag, that
still won't cover two possible combinations – one of which we happen to
need for 'svn blame'.
There are many ways to solve this, from the horrible: have one function
that takes align-left/right and trim-left/right arguments, to the
prolific have 4 functions that each cover one of the 4 cases. Or we can
have two functions that align and two functions that trim, which is
still 4 functions, but a different 4.
I'd prefer to implement just the functions that we actually use:
align-left-trim-right and align-right-trim-right. I saw that svnbrowse
uses the current ..._align_right() but I suspect that's not the intent,
since in most cases trimming text on the right makes more sense than on
the left.
-- Brane
P.S.: To remain LTR-agnostic we could say 'start' and 'end' instead of
'left' and 'right', but, eh, our output isn't all that LTR agnostic anyway.
