Re: [PATCH] Re: double-width characters in tables

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Bastien <bzg@altern.org> writes:

> Hi Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> -		    l (max 1 (- (match-end 0) (match-beginning 0) 3))
>> +		    l (max 1
>> +			   (- (org-string-width
>> +			       (buffer-substring
>> +				(match-end 0) (match-beginning 0))) 3))
>
> (Why not just (org-string-width (match-string 0))?)
>
> Let me know when you're done with extensive testing for this!

I think the reason I went with buffer-substring is that it will *fix*
messed up justification. (match-string 0) will not mess up the
justification if it's already correct, but it won't fix it if it isn't.

Actually, shortly after sending that patch I moved to using
buffer-substring-no-properties, which has the added benefit that fields
with links or other types of hidden text will justify correctly. Unless
I'm mistaken, putting links in table fields will currently result in
too-short justification as handled by org-table-justify-field-maybe (as
always, a full re-align with org-table-align fixes things). Unless the
buffer-substring call is particularly expensive, I think it's worth it.

Re testing: apart from mixing scripts and languages in one field, what
else should be tested? You mentioned cleaning up other problems while
we're at it -- does anyone have anything outstanding?

Inevitably (I think), none of this works when the wrong typeface is
being used for particular characters. I have no specifications for
Cyrillic, for example, which means my system renders it in with a
Chinese typeface, resulting in double-wide glyphs for characters that
should be single-width, and bad table justification. I think this has to
be addressed by the user.

E