Re: Better handling of wide glyphs (ask the terminal, not wcwidth)

[Bart Schaefer <schaefer@brasslantern.com>]

On Nov 5, 11:04pm, Daniel Hahler wrote:
}
} This method gets provided as a shared object then, which allows to
} LD_PRELOAD it (overwriting wcwidth and wcswidth). In this case Zsh
} will use the same method, and everything is fine!
}
} But this shows that there is a problem between Zsh and the terminal,

Just to clarify, you mean the problem "between Zsh and the terminal" is
present even *with* this LD_PRELOAD?

} So I wondered if Zsh could be smarter even without the custom
} wcwidth(3) in LD_PRELOAD: there is CSI 6 n ('\e[6n'), which can be
} used to ask the terminal about the current position.

This is error-prone (network inefficiency/inconsistency may cause it to
fail) and in most cases zsh internals will be asking for the width of
a character that isn't on the screen yet at all, or at least is not in
the position where the cursor is located.

So for this to work we'd have to move the cursor to an innocuous spot
(already difficult enough with terminal variances), print CIS 6, read
the position, print the character we care about, print CIS 6 again,
read again, and finally erase what we just did (with no way to put
back what was overwritten), all while hoping that the network didn't
glitch on us in the meantime.  That's a lot of round trips to the
terminal for what might be inside a loop over a long string.

} What do you think?

I think unicode glyphs have been allowed to go entirely overboard.  I
blame Sirius Cyberne -- er, I mean, Apple.

A zsh module that reads glyph widths from a config file might be a way
to approach this, plus a utility to generate such a configuration from
the terminal -- sort of a termcap library for glyphs.