On Sun, Jan 08, 2017 at 11:13:52AM -0700, Jaimos Skriletz wrote: > On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote: > >> Here is an old (minor) bug that is lurking in the Debian BTS. > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363 > >> > >> The bug is that when assigning non ASCII keys as hot keys in a Menu, > >> the underline underlines the non ASCII character and the one after it. > > > > Hotkeys must be printable 7 bit Ascii characters, which is > > probably not documented. The reason for this is that the hotkey > > is specified as a substring from the item label (e.g. "á") instead > > of a key name ("aacute"). X has no real way to convert a string > > into a key name or vice versa, so hotkeys work only for keys where > > both representations are the same. > > > > If keybindings for non 7 bit ASCII keys don't work, documentation > could be useful. Though this has been around for a long time and not > many seem to mention it so it probably isn't a big deal in the overall > picture.
This may be a real issue for automatic hotkeys in languages other than English. Words beginning with non-latin letters like Ü, Á etc. are not uncommon in European languages. > > I can reproduce the drawing bug. Maybe we should simply disable > > hotkeys completely for anything not 7 bit ASCII. > > > > Disabling the keys since they aren't working anyways and giving a > warning may be useful for those who try to use non ASCII characters. > Such a warning should only trigger when items are added to the menu, > not each time the menu pops up. Yes, a warning if it's a manual hotkey, at least. Not sure what to do about automatic ones. It may be confusing to get no hotkey without a warning (and without iconv we can't reliably look past the first letter). On the other hand the user has probably not asked for warnings regarding automatic hotkeys. > At least this way if anyone tries to use non-ASCII characters they are > correctly informed that they do not work and this can move to a > feature request to add support for these keys. I *could* implement the table I mentioned (there are several version floating around the net) to get non-Ascii hotkeys working, but then we might as well leave hotkeys as they are in fvwm-2.x and rewrite the hotkey syntax to allow specifying key names for fvwm-3.x. E.g. "&(aacute)" or something like that, or even ábc use "á" as hotkey if iconv support is compiled in (using a built-in table), otherwise no automatic hotkey. Maybe rather use b as the hotkey as there's no guarantee the keyboard has a key for á? &ábc if iconv support is compiled in; automatic hotkeys work; use built-in table &(aacute) string representation of a keysym (XStringToKeysym) &(12345) numeric representation of a keysym Too stupid that X has no way to convert keysyms into printable strings and vice versa. Ciao Dominik ^_^ ^_^ -- Dominik Vogt