xmonad-contrib
xmonad-contrib copied to clipboard
xmonad
EZConfig binding with "ç"
On my keyboard layout, ç is where ; is on the us layout. So it is very convenient to bind a command to it.
EZConfig's regular keys stop short of ç. I'd like, if possible, to extend them. I myself can't think of any principled way of selecting how much to expand it to.
Of course, I can already bind to ç by using xK_cedilla, so this isn't a big deal.
EZConfig is almost aggressively US-only. I've grumped about this before.
On Thu, Jan 5, 2017 at 10:56 AM, elvis-sik [email protected] wrote:
On my keyboard layout, ç is where ; is on the us layout. So it is very convenient to bind a command to it.
EZConfig's regular keys stop short of ç. I'd like, if possible, to extend them. I myself can't think of any principled way of selecting how much to expand it to.
Of course, I can already bind to ç by using xK_cedilla, so this isn't a big deal.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/xmonad/xmonad-contrib/issues/135, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8SoNMOFZVeHqsJpWyyQjVXu2kdJWvuks5rPRK4gaJpZM4Lb1N6 .
-- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Sorry about that! I wrote the code in... (checks git history)... 2008, when I was pretty naive about non-ASCII things. So the line of code in question is this:
https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Util/EZConfig.hs#L430
i.e. zip ['!'..'~'] [xK_exclam..xK_asciitilde] . Any ideas what this should be changed to? Is there, e.g., another convenient block of consecutive Unicode codepoints which commonly occur as keys on various non-US keyboard layouts? Or is there a list of such keys/codepoints somewhere?
Wow @byorgey, have you been using xmonad for that long?
I tried finding a list of most common codepoints in keyboards across the world but couldn't. What would stop us from simply including everything?
The absolute minimum is probably U+00A1 .. U+00FF; even better would be U+00A1 .. U+02AF. Eastern Europe would likely appreciate U+0400 .. U+0527 (after that, and in the omitted gap, it gets dicier because there's a bunch of unassigned blocks with small locale blocks interspersed and modifiers etc.). We can't reasonably accommodate everyone, but that would likely cover over 90% of our users.
I'm half tempted to go poke at the Unicode extraction scripts in the rakudo repo and see if there's anything that could be used to autogenerate script ranges for base keys; while it's likely that some people would also like to bind commands to modifier dead keys, that's just not ever going to work well with a string-based key format.
On Mon, Jan 9, 2017 at 5:51 PM, Brent Yorgey [email protected] wrote:
Sorry about that! I wrote the code in... (checks git history)... 2008, when I was pretty naive about non-ASCII things. So the line of code in question is this:
https://github.com/xmonad/xmonad-contrib/blob/master/ XMonad/Util/EZConfig.hs#L430
i.e. zip ['!'..'~'] [xK_exclam..xK_asciitilde] . Any ideas what this should be changed to? Is there, e.g., another convenient block of consecutive Unicode codepoints which commonly occur as keys on various non-US keyboard layouts? Or is there a list of such keys/codepoints somewhere?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xmonad/xmonad-contrib/issues/135#issuecomment-271433505, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8SoM5GxWD8PpDlViEAZuJqCxxtV97bks5rQrnngaJpZM4Lb1N6 .
-- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Actually I wonder if it's worth supporting <U+xxxxxx> (1-6 hex digits) for arbitrary keys. Most (not all, but IIRC true until the historical extended keysyms up around 0xFD00) of the extended keysyms are just the Unicode codepoints.
On Mon, Jan 9, 2017 at 6:50 PM, Brandon Allbery [email protected] wrote:
The absolute minimum is probably U+00A1 .. U+00FF; even better would be U+00A1 .. U+02AF. Eastern Europe would likely appreciate U+0400 .. U+0527 (after that, and in the omitted gap, it gets dicier because there's a bunch of unassigned blocks with small locale blocks interspersed and modifiers etc.). We can't reasonably accommodate everyone, but that would likely cover over 90% of our users.
I'm half tempted to go poke at the Unicode extraction scripts in the rakudo repo and see if there's anything that could be used to autogenerate script ranges for base keys; while it's likely that some people would also like to bind commands to modifier dead keys, that's just not ever going to work well with a string-based key format.
On Mon, Jan 9, 2017 at 5:51 PM, Brent Yorgey [email protected] wrote:
Sorry about that! I wrote the code in... (checks git history)... 2008, when I was pretty naive about non-ASCII things. So the line of code in question is this:
https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/ Util/EZConfig.hs#L430
i.e. zip ['!'..'~'] [xK_exclam..xK_asciitilde] . Any ideas what this should be changed to? Is there, e.g., another convenient block of consecutive Unicode codepoints which commonly occur as keys on various non-US keyboard layouts? Or is there a list of such keys/codepoints somewhere?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xmonad/xmonad-contrib/issues/135#issuecomment-271433505, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8SoM5GxWD8PpDlViEAZuJqCxxtV97bks5rQrnngaJpZM4Lb1N6 .
-- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Wow @byorgey, have you been using xmonad for that long?
@elvis-sik yep, it's even a bit hard for me to believe... I got involved with xmonad just as it was getting off the ground (and I was first learning Haskell).
Most (not all, but IIRC true until the historical extended keysyms up around 0xFD00) of the extended keysyms are just the Unicode codepoints.
Are you sure? Looking at my keysymdef.h, it seems like some have 0x1000000 added to them, and some seem simply unrelated. e.g.
#define XK_Arabic_semicolon 0x05bb /* U+061B ARABIC SEMICOLON */
@elvis-sik I pushed a commit to byorgey/xmonad-contrib (see link above) which adds Latin1 characters. Can you test it and make sure it works as expected? I can't easily test it since I don't have any Latin1 characters on my (US) keyboard.
Of course we can continue talking about adding more, e.g. up through 0x2ff and beyond, but I figured this makes for a good start. If you (or anyone) can confirm it works then I'll push it to the main repo.
@pjones I'd love to merge this but I can't test it at all. If anyone reading this has some non-ASCII characters on their keyboard, please try this out!
Sorry for the lack of response, I was on a trip and forgot later. I can test this with ç and Ç easily. I doubt I could do it with others as I have to press two keys to type ´, é and the like.
I don't know yet how to test it. If you can't answer this in time, I will try to figure it out on my own. I am thinking of using xmonad-testing but cloning your fork and replacing xmonad-contrib on xmonad-testing with it.
I am thinking of using xmonad-testing but cloning your fork and replacing xmonad-contrib on xmonad-testing with it.
Yes, I think that ought to work.
Sorry for having taken so long. I got around to compile and test it, using the xmonad-testing repo. Had to spend some time scratching my head to figure out how to make it compile, but eventually I did and it worked.
I tested a vanilla config with the addition of
`additionalKeysP` -- Add some extra key bindings:
[ ("C-ç", spawn "urxvt")
, ("C-t", spawn "urxvt")
]
C-ç worked as expected.
There's not much else I can test, I believe. I tried binding é, but as I mentioned, that takes me two keystrokes to input, and it did not work (as I expected). Here's my keyboard https://en.wikipedia.org/wiki/Portuguese_keyboard_layout#/media/File:KB_Portuguese_Brazil.svg I believe ç is the only non-ascii character I can easily input.
I can try switching the system's keyboard layout. I have a script handy to switch to Russian, and I tried it, but latin1 has no cyrillic.
@elvis-sik Thanks! Then I think I'll go ahead and propose this for merging.
I think this can be closed now, given that #158 was merged. Feel free to reopen if that didn't address the issue, or if anyone would like to propose extending further the range of keys we can handle. (If so, it seems like this might be relevant: http://www.cl.cam.ac.uk/%7Emgk25/ucs/keysyms.txt .)
Hey, just stumbled upon this issue. Would be really nice to support wider range of keys. Linked keysyms.txt looks pretty good. But it would be even nicer to support arbitrary unicode symbols. For example, the following code allows to use keys like <0x06ad>:
import Numeric (readHex)
-- ...
parseKey :: ReadP KeySym
parseKey = parseRegular +++ parseSpecial +++ parseHex
parseHex :: ReadP KeySym
parseHex = do
_ <- char '<'
_ <- char '0'
_ <- char 'x'
key <- readS_to_P readHex
_ <- char '>'
return key
What I find confusing is relation between Unicode hex (e.g. U+0490) and X11 hex (e.g. 0x06ad). I am using keysymdef.h to lookup X11 code by Unicode. I feel like I am missing something trivial and supporting U+0490 would be easy.
If someone finds it useful, I can prepare a PR.
As you'll note earlier, I had proposed this already. With nobody actually calling for it, it was dropped, but you might be the one to push it.
As for the relationship between Unicode codepoints and various Latin-n characters, there isn't one. X predates Unicode by several years, and by the time it adopted it we were stuck with a number of oddball keysyms having nothing to do with codepoints. I suspect we'll need a translation table.
I mostly thought I could rope you into a contribution :) I don't really need this, but I've opened https://github.com/xmonad/xmonad-contrib/issues/764 to perhaps give this issue a little bit more visibility, in case people are interested. I will close this issue for now; discussion of the feature should happen in the new thread