Greetings. On Sun, 14 Apr 2013 08:10:22 +0200 Random832 <random...@fastmail.us> wrote: > I am forced to ask, though, why character cell values are stored in > utf-8 rather than as wchar_t (or as an explicitly unicode int) in the > first place, particularly since the simplest way to detect a wide > character is to call the function wcwidth. What was the reason for this > design decision? It doesn't save any space, since on most systems > UTF_SIZ == sizeof(int) == sizeof(wchar_t).
That design decision can change when I’m actually implementing the dou‐ ble‐width and double‐height support in st. The codebase is small enough to change such a type in less than 10 minutes. So no religion was intro‐ duced here. > And I don't know the st codebase well enough (or at all, really) to tell > at a glance what would have to be changed to be able to support a > double-width character cell, or to support wrapping to the next line if > one is output at the second-to-last column. I hadn't yet the time to read all the double-width implementations in other terminals so st would do the »right thing« in implementing all questionable cases. Double‐width characters are like BCE a design decision applications need adapt to. Some corner cases I haven't yet found a good answer to: * Is there any standard for this except for setting the flag in terminfo and taking up two cells in the terminal? * If st has double-width default. * What happens if the application does naive character counting? Will layouts break? * Is there some way to tell the application that we have double-width support enforced except for the terminfo? * How do applications implement this? Is there some historical cruft that will break? * With an option to toggle the double-width handling: * Is this needed for tmux, screen or other terminal proxies that for example miss BCE too? These are the questions I miss an answer too before implementing this. The code isn’t a problem. Sincerely, Christoph Lohmann