It seems like we know at this point if the displayWidth is greater than or equal to the maxWidth. Could we actually return here instead of calling TruncateByWidth() ?

for index, r := range rs {
    width := charWidth(r)
    switch {
    case displayWidth + width == maxWidth && index + 1 == len(rs):
        return s
    case displayWidth + width >= maxWidth:
        return string(rs[:index]) + "…"
    }
    displayWidth += width
}
return s

If this works, then I think we can simplify the maxwidth == 1 case as well and we could remove TruncateByWidth() entirely.

These tests would be great as a test table.

var testcases = []struct{
    source string
    width int
    expected string
} {
    {source: "t🐳ststring", width: 0},
    ...
}

for _, testcase := range testcases {
    assert.Equal(t, testcase.expected, Ellipsis(testcase.source, testcase.width))
}

Also please use assert.Equal() instead of if x != y { t.Fatalf(...) }

Modified. Sorry for the delay.

Although the pr is merged, if u are free @dnephin , I have a low level quetion why should we use assert.Equal() instead of if x != y { t.Fatalf(...) }? What's the disadvantages of t.Fatalf? (☉㊀☉)

@charrywanganthony

• assert.Equal() can't lie. It will always print the real value for the two values being compared. If you write if x != y { t.FatalF(msg) } the msg could be incomplete, or misleading, or even completely wrong, which makes debugging the failure more difficult. You can always provide extra msgAndArgs to assert.Equal() as the 4+ argument.
• assert.Equal() is less verbose, so it keeps test smaller and easier to read
• assert.Equal() reads in the affirmative, where as conditions for if x != y ... are always the inverse. I want x == y, but I have to write x != y.

These points may not be relevant in all cases, but it's easier to be consistent and just use it everywhere.

Perhaps we need some more information here what "width" is, but I don't have a good suggestion at this moment.

Modified. Sorry for the delay.

❤️ … nice!