Hi NilsOla, NilsOla Nilsson wrote on Thu, Jul 11, 2019 at 11:24:24PM +0200:
> I am using cwm and ksh and at present my compose key > work in st and in gvim, but not in xterm. > I am on current updated a few weeks ago. Oh. Thank you for the hint. Given my clumsiness with X keyboard configuration, i assumed it was just me, but your additional data indicates there may actually be a regression in xterm(1). Who knows what a GTK leviathan like gvim is doing. But suckless software is about the opposite of bloatware and i would be quite surprised if it internally re-implemented the Compose mechanism. So the fact that Compose works in the x11/st(1) port (which i can confirm) means that i probably do have Compose correctly configured and that xterm(1) is somehow breaking the characters it receives from X - not all of them, but those where Compose was involved. The above suspicion is supported by the fact that Compose also works in xedit(1). It even works in xclipboard(1), xman(1), nedit(1), except that these programs don't support UTF-8 but appear to be hardcoded to Latin-1, such that the entered UTF-8 characters appear as garbage two-character sequences. To me, this looks suspiciously like a bug now. :-( Yours, Ingo > On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote: > > Hi Ian, > > > > ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200: > > > > > While I'm personally only or mainly interested in Alt+numeric input, > > > if altnumd existed, it would probably be comparatively easy to then > > > extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U > > > becoming a reserved keyword unambiguously signifying that what follows > > > will be a Unicode code point between U+0000 and U+10FFFF. > > > > There is no reason to make it different. ASCII is a subset of Unicode, > > with the same numbering. So the "U" looks redundant to me. > > > > > There's a huge competence gap between us, > > > > Quite likely. I'm so clueless that right now, i can't even seem to get > > Compose to work even though i'm sure i had it working in the past. > > This is on amd64-current, inside xterm(1) and ksh(1): > > > > $ locale > > LANG= > > LC_COLLATE="en_US.UTF-8" > > LC_CTYPE="en_US.UTF-8" > > LC_MONETARY="en_US.UTF-8" > > LC_NUMERIC="en_US.UTF-8" > > LC_TIME="en_US.UTF-8" > > LC_MESSAGES="en_US.UTF-8" > > LC_ALL=en_US.UTF-8 > > $ setxkbmap -query -v -v -v > > Setting verbose level to 8 > > locale is en_US.UTF-8 > > Trying to load rules file ./rules/base... > > Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base... > > Success. > > Applied rules from base: > > rules: base > > model: pc105 > > layout: de > > Trying to build keymap using the following components: > > keycodes: xfree86+aliases(qwertz) > > types: complete > > compat: complete > > symbols: pc+de+inet(pc105)+terminate(ctrl_alt_bksp) > > geometry: pc(pc105) > > rules: base > > model: pc105 > > layout: de > > > > At this point, the caps key toggles caps lock, i.e. pressing > > > > caps a caps a > > > > results in the input "Aa". > > > > $ setxkbmap -option compose:caps -v -v -v > > Setting verbose level to 8 > > locale is en_US.UTF-8 > > Trying to load rules file ./rules/base... > > Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base... > > Success. > > Applied rules from base: > > rules: base > > model: pc105 > > layout: de > > options: compose:caps > > Trying to build keymap using the following components: > > keycodes: xfree86+aliases(qwertz) > > types: complete > > compat: complete > > symbols: pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps) > > geometry: pc(pc105) > > > > Now, the caps key no longer toggles caps lock and becomes a dead key, > > i.e. pressing > > > > caps , c caps " a > > > > results in the input "ca". However, the resulting input is really > > ASCII-c ASCII-a rather than the expected c-cedille a-umlaut. > > It looks like Compose works well enough to discard the , and ", > > but not well enough to actually generate non-ASCII characters. > > > > Somewhat grumpy today, > > Ingo > > -- > Nils Ola Nilsson, 🐞 email nils...@abc.se, tel +46-70-374 69 89