On Tue, Sep 25, 2018 at 04:28:22PM -0700, AR Garbe wrote:
> This is something I was considering, however it looks like the water
> of the babie's bathtub is poisoned with freetype2/fc bacteria. I don't
> wanna introduce abstractions that might be premature, hence I suggest
> to fully revert back to XFont* API until something like this is proven
> to be work properly. It can only improve the performance of st as well
> ;)
Actually, the real pollution comes from harfbuzz(freetype2 and fc are specks in
comparison). But all that is for the rendering part only.
I don't remember how terminal input is done, but it seems that NFD normalized
unicode does not work: you would get 2 unicode code points for a 'é' input, the
'e' + 'combining accent', namely terminal input would have to be transactional
at the char level, or the terminal would render 'e' then the 'combining accent' and
not 'é' as it should be. Or maybe unicode does contain "transactional code
points" already.
:(
--
Sylvain
Received on Wed Sep 26 2018 - 04:08:03 CEST