The russian keyboard layout does neither contain a dead-acute nor a combining-acute. The acute accent is needed to mark stressed characters, often used in books about the Russian language. It would be nice if the russian xkb map would contain at least the combining acute accent.
Usually Russian layout is used with some ASCII-based layout which usually has these characters. As a Russian, I do not see any particular place and need for acutes in the Russian layouts/variants. And you always have ability to customize things with .Xmodmap or just use something like gcharmap.
I guess I explained why there is a need for it, almost all books about Russian use these accents. There are not only for learning the pronounciation (e.g. алкого́ль/а́лкоголь), but to differentiate the meaning of words. E.g. дыши́те/ды́шите, плачу́/пла́чу, дорога́/доро́га, пища́/пи́ща, подсыпа́ть/подсы́пать, мука́/му́ка, ва́жны/важны́, etc.pp. I don't think that it makes sense that every linguistic faculty or language center creates its own keymap, like I have done for myself. A default combining acute could be something to differientiate x.org from other OSs. It it could not be on the default russian keymap, what about a layout variant?
Having easily available acutes would be nice indeed, but let's face two simple facts: 1. By creating a new keyboard layout with acutes you lose at least 6 useful characters - per one for each vowel. If you take a closer look at your keyboard, you most likely won't find a single button that you would sacrifice to an acute. 2. Spellchecker will blame you over and over again unless you volunteer to introduce support for acutes to Lebedev's aspell/ispell dictionary.
> I don't think that it makes sense that every linguistic faculty or language > center creates its own keymap, like I have done for myself. A default combining > acute could be something to differientiate x.org from other OSs. Most of the existing assignments are necessary - I cannot imagine removing them (moreover, there are some characters, more important than acutes, which would be nice to have). But since original keyboard was designed for ASCII (having 6 characters less), we just used to the fact that all missing characters are taken from the ASCII-based group. Why couldn't linguists use the same approach? Also, which characters would you consider as less important than acutes? PS And I do not see any real ground to introduce 3rd shift level just because of acutes.
First, Alexandre Prokoudine and Sergey V. Udaltsov thanks for your comments. (In reply to comment #3) > 1. By creating a new keyboard layout with acutes you lose at least 6 useful > characters - per one for each vowel. That is not necessarily true, many layouts have the accents as a dead key. That means that one needs to press the dead-acute and then the vowel, or first the vowel and then the combining acute. > If you take a closer look at your keyboard, > you most likely won't find a single button that you would sacrifice to an > acute. That is true on a standard keyboard. That is why I believe that introducing a 3rd level might be the only realistic solution. > 2. Spellchecker will blame you over and over again unless you volunteer to > introduce support for acutes to Lebedev's aspell/ispell dictionary. I don't think that it is worthwhile to have the words with acutes in the dictionary since they are not used in normal conversation. For spellchecking it is enough to strip the combining acutes (U+0301) of the text. (In reply to comment #4) > Most of the existing assignments are necessary - I cannot imagine removing > them (moreover, there are some characters, more important than acutes, which > would be nice to have). But since original keyboard was designed for ASCII > (having 6 characters less), we just used to the fact that all missing > characters are taken > from the ASCII-based group. Why couldn't linguists use the same approach? Unfortunately that does not work with acutes, they have to be entered directly before (dead-acute) or behind (combining-acute) the char to be accentuated. > Also, > which characters would you consider as less important than acutes? That is one reason why I have filled this bug report since I did not know a better place to discuss this. > PS And I do not see any real ground to introduce 3rd shift level just because > of acutes. Indeed I think a additional third level is a good idea. It does not change the behaviour of the normal keyboard if one does not have a key assigned to level 3 shift. And chances are good that it works for most people using accents out of the place since they often have a level 3 shift (Alt Gr) assigned anyway because they need it for there (foreign) keyboard layouts anyway. The only difficulty I see is that Cyrillic vocals with accent are combined. Theoretically Is it possible to assign, e.g. <U+0430><U+0301> to <level 3 shift> + <а>?
(In reply to comment #5) First of all, nice to see that I´m not the only one looking for such a feature. I was just reading a little bit about how key assignment works in x.org, so maybe i can add some useful information. I got my information mainly from http:/ /kvota.net/guadec/localised-desktop-talk/ and http://www.unicode.org/. I use x.org on a debian system, the x server identifies itself as follows: X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-4 20060114230205 David Nusinow <dnusinow@debian.org>) With regards to the dead-key solution, there is the problem, that the character in question (U+0301) is not defined in /usr/X11R6/include/X11/keysymdef.h and therefore not adressable in a keyboard layout. The existing dead_acute seems to be something different. The solution of introducing a 3rd level suffers the same problem, but has apart from that another peculiarity: it is apparently not possible to map the actual character AND the diacritical mark to a key via the definition of a keyboard layout. To achieve that it would be necessary to modify /usr/X11R6/lib/X11/ locale/en_US.UTF-8/Compose or to create ~/.Xcompose with the necessary rules for every user. Unfortunately Unicode does not include accented Cyrillic letters, so I don´t see any other solution than the two mentioned, which leads to the same problem: character U+0301 (better: the whole range U+0300 - U+036F) not being available as keysymbol. I would appreciate it very much, if there was a nice solution to this. Regards, Matthias Noe
(In reply to comment #6) > With regards to the dead-key solution, there is the problem, that the > character in question (U+0301) is not defined in > /usr/X11R6/include/X11/keysymdef.h and > therefore not adressable in a keyboard layout. The existing dead_acute seems > to be something different. Seems you are right, there is no combining acute anymore. It worked previously, see http://qa.openoffice.org/issues/show_bug.cgi?id=40933 But the dead acute still works with vowels in openoffice.org. Dead acute + vowel gives vowel+combining acute. > The solution of introducing a 3rd level suffers the same problem, [...] > To achieve that it would be necessary to modify /usr/X11R6/lib/X11/ > locale/en_US.UTF-8/Compose or to create ~/.Xcompose with the necessary > rules for every user. AFAIK keyboard layouts including Shift-Level-3 (Alt Gr key) and dead keys — and Compose (compose key) are different input systems. P.S.: You might be interested in http://en.wikipedia.org/wiki/X_keyboard_extension
(In reply to comment #7) > Seems you are right, there is no combining acute anymore. It worked previously, > see http://qa.openoffice.org/issues/show_bug.cgi?id=40933 > But the dead acute still works with vowels in openoffice.org. Dead acute + vowel > gives vowel+combining acute. Is this also true for cyrillic vowels? Somehow i never managed to get them. Here is my setup: /etc/X11/xkb/symbols/pc/bg_m (modified version of /etc/X11/xkb/symbols/bg) key <AD01> {[ Cyrillic_ya, Cyrillic_YA, apostrophe, combining_acute ]}; xev shows the following (pressing and releasing in order: q, alt gr+q, alt gr+shift+q): KeyPress event, serial 27, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3367778, (-197,461), root:(530,506), state 0x0, keycode 24 (keysym 0x6d1, Cyrillic_ya), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3367861, (-197,461), root:(530,506), state 0x0, keycode 24 (keysym 0x6d1, Cyrillic_ya), same_screen YES, XLookupString gives 0 bytes: KeyPress event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3370190, (-197,461), root:(530,506), state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3371108, (-197,461), root:(530,506), state 0x80, keycode 24 (keysym 0x27, apostrophe), same_screen YES, XKeysymToKeycode returns keycode: 48 XLookupString gives 1 bytes: (27) "'" XmbLookupString gives 1 bytes: (27) "'" XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3371249, (-197,461), root:(530,506), state 0x80, keycode 24 (keysym 0x27, apostrophe), same_screen YES, XKeysymToKeycode returns keycode: 48 XLookupString gives 1 bytes: (27) "'" KeyRelease event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3371371, (-197,461), root:(530,506), state 0x80, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: KeyPress event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3373740, (-197,461), root:(530,506), state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3374189, (-197,461), root:(530,506), state 0x80, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3374976, (-197,461), root:(530,506), state 0x81, keycode 24 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x2000001, root 0x4c, subw 0x0, time 3375126, (-197,461), root:(530,506), state 0x81, keycode 24 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: Funny enough, I cannot use <combining_acute>, but <dead_acute> doesn´t work either. In fact, none of the deadkeys is working as expected, even though xev shows the correct keysym... Seems that I have to investigate that further. Could you please post the line of your /usr/X11R6/include/X11/keysymdef.h where <combining_acute> (U+0301) is defined? To add something more to the confusion, i found the following imho contradicting lines at http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt 0xfe51 U0301 f # dead_acute [...] # (Unicode combining characters have no direct equivalence with # keysyms, where dead keys are defined instead) 0x1e9f U0303 r # combining_tilde 0x1ef2 U0300 r # combining_grave 0x1ef3 U0301 r # combining_acute 0x1efe U0309 r # combining_hook 0x1eff U0323 r # combining_belowdot > AFAIK keyboard layouts including Shift-Level-3 (Alt Gr key) and dead keys — and > Compose (compose key) are different input systems. > > P.S.: You might be interested in http://en.wikipedia.org/wiki/ X_keyboard_extension Seems you are right. Now I really wonder if there is a (simple) way to map a composed character to one key.
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
When was this supposed to be fixed? Please explain in detail.
Of course it is not fixed. In a word, Helge, could you please attach the variant you'd propose. Even if we do not accept it - it would still be available to people as a patch. If you ask me, I'd advise to base your layout on ru(winkeys) as most widely used. (In reply to comment #10) > When was this supposed to be fixed? Please explain in detail. >
(In reply to comment #11) > In a word, Helge, could you please attach the variant you'd propose. Even if > we do not accept it - it would still be available to people as a patch. If you > ask me, I'd advise to base your layout on ru(winkeys) as most widely used. IMHO it would make most sense to assign the accentuated characters to the vowels with level-3-shift. This way the base layout would stay as is and only those who need the additional characters could assign level-3-shift to AltGr (e.g.). As stated in comment #5, I do not know how to assign two chars to one key: > The only difficulty I see is that Cyrillic vocals with accent are combined. > Theoretically Is it possible to assign, > e.g. <U+0430><U+0301> to <level 3 shift> + <а>? Therefore I am not able to write a patch at this moment.
> IMHO it would make most sense to assign the accentuated characters to the > vowels with level-3-shift. This way the base layout would stay as is and only > those who need the additional characters could assign level-3-shift to AltGr > (e.g.). I would prefer new variant (even if is "include"s the original one). > As stated in comment #5, I do not know how to assign two chars to one key: > > The only difficulty I see is that Cyrillic vocals with accent are combined. > > Theoretically Is it possible to assign, > > e.g. <U+0430><U+0301> to <level 3 shift> + <а>? No, in XKB it is not possible. You have to use Compose. Which is beyond the scope of xkeyboard-config.
(In reply to comment #13) > > As stated in comment #5, I do not know how to assign two chars to one key: > > > The only difficulty I see is that Cyrillic vocals with accent are combined. > > > Theoretically Is it possible to assign, > > > e.g. <U+0430><U+0301> to <level 3 shift> + <а>? > No, in XKB it is not possible. You have to use Compose. Which is beyond the > scope of xkeyboard-config. Would it be possible to have an RFE for this?
> > No, in XKB it is not possible. You have to use Compose. Which is beyond the > > scope of xkeyboard-config. > > Would it be possible to have an RFE for this? > RFE for what? For putting Compose files into xkeyboard-config scope? I could consider it but I'd give no promises. Or for changing XKB extension in order to support multiple chars for one key? I'm afraid it is a major change which would be difficult to implement. You can talk to Daniel Stone about it - but I would be surprised if he agrees - especially taking the fact that you can have required functionality using Compose.
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
Since noone contributed a working patch (and no activity shown), I am closing this one.
Why are you closing this bug as INVALID? I do not have the power and knowledge to fix it myself. IMHO closing as WONTFIX would be more appropriate.
Sorry, the INVALID state just marked there was no reply on my last comment. Did you discuss the Compose thing with Daniel Stone? And it is INVALID for xkeyboard-config, actually, since the functionality you're asking (in XKB) is not available on lower levels. Or you have to implement it with the Compose - which is, again, not xk-c scope.
Sorry, I did not discuss anything with Daniel Stone. I do not know who he is or how to reach him. Also I felt that I do not have enough knowledge to discuss the topic thoroughly at this level. Thanks for your effort.
The UTF-8 Compose tables currently have support for these Cyrillic characters by way of dead_acute: <dead_acute> <Cyrillic_GHE> : "Ѓ" U0403 # CYRILLIC CAPITAL LETTER GJE <dead_acute> <Cyrillic_KA> : "Ќ" U040C # CYRILLIC CAPITAL LETTER KJE <dead_acute> <Cyrillic_ghe> : "ѓ" U0453 # CYRILLIC SMALL LETTER GJE <dead_acute> <Cyrillic_ka> : "ќ" U045C # CYRILLIC SMALL LETTER KJE Those are probably the only ones defined in NFC. XIM does support strings as the composed output, so we can add lines which use dead_acute and a Cyrillic letter to generate that letter followed by a Combining Acute character. And as well for the other diacritics. The same goes for breve, diaeresis, doubleacute, grave and macron, all of which are also supported for NFC Cyrillic characters. Similarly, there are several Multi_key inititated compose sequences for Cyrillic, and new ones can be added as per the above. OTOH, since the results of the dead_key or Multi_key sequences are themselves sequences, it may be better for the keyboards to support the combining characters directly rather than dead keys. (The difference, of course, is that dead keys precede the base character's key and combining characters are input after the base character.) What does the Cyrillic community actually want?
This is the list of precomposed Unicode characters in the Cyrillic Unicode block. The last column shows the corresponding diacritic mark, when you decomposed. Decomposed: 0x0400, Ѐ ==> Е ̀ 0x300 Decomposed: 0x0401, Ё ==> Е ̈ 0x308 Decomposed: 0x0403, Ѓ ==> Г ́ 0x301 Decomposed: 0x0407, Ї ==> І ̈ 0x308 Decomposed: 0x040C, Ќ ==> К ́ 0x301 Decomposed: 0x040D, Ѝ ==> И ̀ 0x300 Decomposed: 0x040E, Ў ==> У ̆ 0x306 Decomposed: 0x0419, Й ==> И ̆ 0x306 Decomposed: 0x0439, й ==> и ̆ 0x306 Decomposed: 0x0450, ѐ ==> е ̀ 0x300 Decomposed: 0x0451, ё ==> е ̈ 0x308 Decomposed: 0x0453, ѓ ==> г ́ 0x301 Decomposed: 0x0457, ї ==> і ̈ 0x308 Decomposed: 0x045C, ќ ==> к ́ 0x301 Decomposed: 0x045D, ѝ ==> и ̀ 0x300 Decomposed: 0x045E, ў ==> у ̆ 0x306 Decomposed: 0x0476, Ѷ ==> Ѵ ̏ 0x30f Decomposed: 0x0477, ѷ ==> ѵ ̏ 0x30f Decomposed: 0x04C1, Ӂ ==> Ж ̆ 0x306 Decomposed: 0x04C2, ӂ ==> ж ̆ 0x306 Decomposed: 0x04D0, Ӑ ==> А ̆ 0x306 Decomposed: 0x04D1, ӑ ==> а ̆ 0x306 Decomposed: 0x04D2, Ӓ ==> А ̈ 0x308 Decomposed: 0x04D3, ӓ ==> а ̈ 0x308 Decomposed: 0x04D6, Ӗ ==> Е ̆ 0x306 Decomposed: 0x04D7, ӗ ==> е ̆ 0x306 Decomposed: 0x04DA, Ӛ ==> Ә ̈ 0x308 Decomposed: 0x04DB, ӛ ==> ә ̈ 0x308 Decomposed: 0x04DC, Ӝ ==> Ж ̈ 0x308 Decomposed: 0x04DD, ӝ ==> ж ̈ 0x308 Decomposed: 0x04DE, Ӟ ==> З ̈ 0x308 Decomposed: 0x04DF, ӟ ==> з ̈ 0x308 Decomposed: 0x04E2, Ӣ ==> И ̄ 0x304 Decomposed: 0x04E3, ӣ ==> и ̄ 0x304 Decomposed: 0x04E4, Ӥ ==> И ̈ 0x308 Decomposed: 0x04E5, ӥ ==> и ̈ 0x308 Decomposed: 0x04E6, Ӧ ==> О ̈ 0x308 Decomposed: 0x04E7, ӧ ==> о ̈ 0x308 Decomposed: 0x04EA, Ӫ ==> Ө ̈ 0x308 Decomposed: 0x04EB, ӫ ==> ө ̈ 0x308 Decomposed: 0x04EC, Ӭ ==> Э ̈ 0x308 Decomposed: 0x04ED, ӭ ==> э ̈ 0x308 Decomposed: 0x04EE, Ӯ ==> У ̄ 0x304 Decomposed: 0x04EF, ӯ ==> у ̄ 0x304 Decomposed: 0x04F0, Ӱ ==> У ̈ 0x308 Decomposed: 0x04F1, ӱ ==> у ̈ 0x308 Decomposed: 0x04F2, Ӳ ==> У ̋ 0x30b Decomposed: 0x04F3, ӳ ==> у ̋ 0x30b Decomposed: 0x04F4, Ӵ ==> Ч ̈ 0x308 Decomposed: 0x04F5, ӵ ==> ч ̈ 0x308 Decomposed: 0x04F8, Ӹ ==> Ы ̈ 0x308 Decomposed: 0x04F9, ӹ ==> ы ̈ 0x308 0x0300: dead_grave 0x0301: dead_acute 0x0308: dead_diaeresis ... All these sequences above are supported in GTK+ 2.14 and I think that X.Org's Compose has the complete list as well. One possible solution to the whole issue might be to make a four-level ru layout, similar to the way the gb layout (and now the gr layout) work. In the gb layout, you get a dozen of dead_keys when you press AltGr + character, in gr you get the 9 dead_keys for Greek. I think that it would be possible to stuck up all characters in the Cyrillic and Cyrillic Extended Unicode blocks in a single four-level layout. In the case of gb, gr, the four-level version of layout is the default layout.
Lads, have a mercy... The author of the bug only wanted accented russian vowels (which is a strange request as such, I as pointed earlier) - not _all_ russian letters (Helge, am I right?) I still think that implementing that as Compose, using dead keys is more logical than adding whole 3rd and 4th levels (just for 5 characters). RAlt key is more useful as another Alt than a way to get 5 extra chars.
Yes, I was looking for a way to mark stress on russian words. AFAIK the stress can only be on a vowel. The problem with the dead key is, that you need to reassign a key for that function, right?
Yes, but finding a place for one dead key is less harm than organizing extra levels IMHO.
Sergey, what key would you propose? There a only 5 non alphanumeric keys left: /.\=- I had a discussion about it at wikipedia: http://en.wikipedia.org/wiki/User_talk:Imz#acute_accent_on_russian_keyboard
Well, there are also shifted numeric ones. What about changing "Shift-2" (mapped to "Double Quote") to "Dead double acute"?
I have re-raised this issue, and submitted a merge request, on the new libX11 issue tracker at <https://gitlab.freedesktop.org/xorg/lib/libx11/issues/104>.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.