On 22/04/28 06:48, Страхиња Радић wrote: > May I ask what shell are you using inside st? The only problem I noticed so > far > with my script, which uses xdotool(1) to type characters, is when I am using > it > while st is specifically executing mksh as a shell. With bash, dash and zsh > emoji are inserted correctly. This is undoubtedly some misconfiguration of > mksh > on my part, which I have yet to figure out in detail.
After some investigation, I discovered the following paragraph in mksh FAQ[1]: > The shell’s utf8-mode before mksh R60 supported only the BMP (Basic > Multilingual Plane) of UCS and mapped raw (extended ASCII) octets, i.e. these > which are not valid UTF-8 BMP codepoints) into the U+EF80‥U+EFFF range, which > is allocated at the CSUR for this purpose. (It otherwise lies in the PUA; > however, there is ambiguity if encountering those UTF-8-encoded, so it > changed > for R60.) The Arithmetic expressions and CAVEATS sections in mksh(1) contain > more details about encoding and mapping. > > As of R60, utf8-mode maps “raw octets” to U-10000080‥U-100000FF, which is > outside the UCS and therefore collision-free. There’s work underway to make > the > shell support the full 21-bit UCS range for R60. Since I'm currently using mksh R59, that part of the mystery is solved as well. **Definitive conclusion: st does not need GNOME, ibus or other bloat (aside from good old native X.Org bloat itself) to support UTF-8 input/output.** [1]: http://www.mirbsd.org/mksh-faq.htm#posix-mode
signature.asc
Description: PGP signature
