(In reply to comment #45)
> (In reply to comment #44)
> > Until a solution is to be found, could 518c769d be reverted for now?
> > Breaking the very standard behavior of right control
> 
> It does not break the very standard behavior of right control any more than
> altrgr breaks the very standard behavior of right alt

For me it does.  My keyboard has an "Alt Gr" label on the AltR key, so it indeed is expected to behave differently from Alt_L, but my ControlR key is labeled as "Ctrl", just like the ControlL key.  And all other keyboards and OSes I ever used did handle ControlR the same as ControlL, as far as I was concerned as a user.

Also, I find it more generically problematic to change the behavior of a common key on a widely used keymap.  For example the change annoyed me for about a month before I took the time to debug this and edit my keymap -- and I can't imagine what a lambda user could do but learn to deal with it.

Also, what is Level5 used for?  IIUC, currently nothing but short-nbsp (or at least that I can find, which is practically the same from a user POV), turning Ctrl_R into a virtually useless key.


So, what can we do?

First, please note, for what is worth, that both Rhythmbox and Totem, which were cited as the applications having a problem with the previous state of things, are not affected anymore.  Rhythmbox don't use Control+Space as a shortcut anymore, and Totem seem to react to any space keysym, no matter the modifiers.
So, unless there actually are other applications using Control+Space and suffering of the issue (Code::Blocks?), the problem does not even exist anymore.
Also, maybe I just don't know how one is supposed to process the events, but those bugs look like an application or toolkit issue to me, is it?


Then, practical changes.  Before the change, Space behaved like this:

 Shift* | Control* | Level3 || keysym    | XLookupString
 ---------------------------||--------------------------
        |          |        || 0x20      | 20
 X      |          |        || 0x20      | 20
        | X        |        || 0x20      | 20
        |          | X      || 0x20      | 20
 X      | X        |        || 0x100202f | e2 80 af
 X      |          | X      || 0xa0      | c2 a0
        | X        | X      || NoSymbol  |
 X      | X        | X      || NoSymbol  |

And now we have:

 Shift* | ControlL | Level3 | Level5 || keysym    | XLookupString
 ------------------------------------||---------------------------------
        |          |        |        || 0x20      | 20
 X      |          |        |        || 0x20      | 20
        | X        |        |        || 0x20      | 00
        |          | X      |        || 0x20      | 20
        |          |        | X      || 0x20      | 20
 X      | X        |        |        || 0x20      | 00
 X      |          | X      |        || 0xa0      | c2 a0
 X      |          |        | X      || 0x100202f | e2 80 af
        | X        | X      |        || 0x20      | 00
        | X        |        | X      || 0x20      | 00
        |          | X      | X      || NoSymbol  |
 X      | X        | X      |        || 0xa0      | (empty)
 X      | X        |        | X      ||           | (no event on Xev???)
 X      |          | X      | X      || NoSymbol  |
 X      | X        | X      | X      ||           | (no event on Xev???)


So.  IIUC, the problem is having naked Space emit the same XLookupString that Control+Space, right?  The new behavior is emitting lookup string "00" with modifier Control, so I guess this is the fix.

So, what about simply changing the original map to have a different lookup string on Control?  Like this:

 Shift* | Control* | Level3 || keysym    | XLookupString
 ---------------------------||--------------------------
        |          |        || 0x20      | 20
 X      |          |        || 0x20      | 20
        | X        |        || 0x20      | 00
        |          | X      || 0x20      | 20
 X      | X        |        || 0x100202f | e2 80 af
 X      |          | X      || 0xa0      | c2 a0
        | X        | X      || NoSymbol  |
 X      | X        | X      || NoSymbol  |


Or, if we don't want to have anything useful using Control, what about moving 0x100202f to Level3?  Like this:

 Shift* | Control* | Level3 || keysym    | XLookupString
 ---------------------------||--------------------------
        |          |        || 0x20      | 20
 X      |          |        || 0x20      | 20
        | X        |        || 0x20      | 00
        |          | X      || 0x100202f | e2 80 af
 X      | X        |        || 0x20      | 00
 X      |          | X      || 0xa0      | c2 a0
        | X        | X      || NoSymbol  |
 X      | X        | X      || NoSymbol  |


Alternatively, the mapping of ControlR to Level5 could be an option (or a slightly different variant, whatever's better).


Anything that could prevent me from manually editing my map to have ControlR again would be totally great.