[cliptext-] clipstr() to width 1: truncate chars having width > 1

[midichef]

Let's say we have a sheet with full-width characters, like あ,

clipstr() currently causes a problem: if we change a column to width 1, each cell's first character is drawn with its full width, causing columns to be misaligned.

This PR changes clipstr() to trim the fullwidth character to '', so that the column will stay aligned:

Note that this affects the behavior of the headers of hidden columns. They currently show the first character even when it's full-width:

but after this PR they will become blank:

I'm fine with blank headers for hidden columns. If we want to solve that, it can be fixed in drawColHeader():

visidata/visidata/sheets.py

Line 741 in 6b0a78a

clipdraw(scr, y+i, x, name, hdrcattr, w=colwidth)

An alternate design for this PR would have clipstr() replace the single chars with trunch:

        if w_s > 1:
            #add these 2 lines to replace the char with trunch:
            if trunch:
                return trunch, dispwidth(trunch)

But then we'd want to disable the use of the truncator-symbol in certain places, like the top of hidden columns. To do that is easy enough, just call the clipstr() or clipdraw() with truncator=''. But locating all those places would be more effort. So I'm submitting this PR, which is a less invasive change.

[saulpw]

Okay. Do we need a for-loop here? Aren't there just two cases?

        if dispwidth(s[0]) == 1:
            return s[0], 1
        else:
            return '', 0

[midichef]

I don't know if there are more cases, as I'm not sure which characters get a width of 0 from wcwidth(). I put the for-loop there to handle a situation where a string starts with multiple characters with wcwidth/dispwidth of 0, followed by a final character that has a dispwidth of 1.

An example of a character that might get a wcwidth() of 0 is u"\u0ccd" # Joiner, Category 'Lo', East Asian Width property 'N' -- KANNADA SIGN VIRAMA, taken from a test in jquast/wcwidth. Visidata's wcwidth() returns 1 for this character. But wcwidth() from jquast/wcwidth returns 0. Measuring a longer similar string with jquast's wcswidth() function: wcswidth("\u0CCD\u0CCDj)" gives a width of 1, though Visidata's dispwidth gives a width of 3.

So even though I don't know offhand of a case where Visidata's wcwidth() gives 0 for multiple characters in a row, I figured that it could happen.

[saulpw]

Hm, I guess VisiData's wcwidth is wrong then. We should be able to come up with some basic strings that use a zero-width joiner like this one and watch them clobber some aspects of the VisiData interface. We may want/have to vendorize jquast/wcwidth and extend it for our purposes.