https://bugs.kde.org/show_bug.cgi?id=396435
--- Comment #23 from Martin Hostettler <textshell-dia...@uchuujin.de> --- (In reply to Mariusz Glebocki from comment #22) > (In reply to Martin Hostettler from comment #21) > > tangent: > > I think in the long run we need some way for applications to download the > > actually used width mapping from the terminal to get decent interoperability > > across versions and different machines in a network. I just notices that > > emoji joining is yet another aspect that needs to be kept in sync between > > terminal and the application. > > There is already POSIX solution which could solve that - wcwidth() and > wcswidth(). The latter could even calculate widths of joined emojis. Sadly, > it works differently on every platform. And there are separate > implementations in Go, Python, etc. > This is why terminals and console programs sometimes try to make its own > table which works the same (or at least is up to date) on every platform. > > Or, if someone likes hacks, LD_PRELOAD=libkonsole_wcwidth.so ;) Well if that would be the solution konsole would just use it, right? But: * There's the private use area. Only a component with access to the font can know what would look right for these characters. (Or the user could configure that, i'm sure most users don't want to do that manually) * width mapping is a moving target as long as unicode evolves. With the current release cycle even a fast moving target. * Rendering breaks badly when values in the terminal and the client application don't match. (that happens to every terminal with a up to date table) * the usage of ssh with terminals means that connections will span systems with differently outdated libraries. * LD_PRELOAD hacks are not really a sustainable solution. For me that sounds a lot like there needs to be a single point of truth in every terminal session. As long as things move faster than installations update and there is no standard all stakeholders can agree on (and UAX #11 explicitly disclaims being for "modern terminal emulators") there needs *some* way for applications to get this information. From the terminals i looked at only urxvt really buys in to "trust the system libc". And konsole, vte and xterm (i have to assume) intentionally diverge from what libc does. I think from the perspective of a client library the equivalent of roughly one full screen update with a decently sized terminal in data transfer would be an quite attractive trade of ;) -- You are receiving this mail because: You are watching all bug changes.
