Bug 2793 - acute accent on russian keyboard
acute accent on russian keyboard
Status: RESOLVED INVALID
Product: xkeyboard-config
Classification: Unclassified
Component: General
unspecified
x86 (IA32) Linux (All)
: high enhancement
Assigned To: xkb
: movetoxkc
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-23 13:15 UTC by Helge Hielscher
Modified: 2008-11-28 06:51 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Hielscher 2005-03-23 13:15:15 UTC
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.
Comment 1 Sergey V. Udaltsov 2006-04-05 09:31:03 UTC
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.
Comment 2 Helge Hielscher 2006-04-05 12:10:16 UTC
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?
Comment 3 Alexandre Prokoudine 2006-04-06 05:54:47 UTC
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.
Comment 4 Sergey V. Udaltsov 2006-04-06 06:05:47 UTC
> 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.
Comment 5 Helge Hielscher 2006-04-07 04:28:47 UTC
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>
+ <а>?
Comment 6 Matthias Noe 2006-04-07 09:01:44 UTC
(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
Comment 7 Helge Hielscher 2006-04-07 15:58:21 UTC
(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
Comment 8 Matthias Noe 2006-04-07 20:47:08 UTC
(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.
Comment 9 Timo Jyrinki 2007-02-22 14:26:29 UTC
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.
Comment 10 Helge Hielscher 2007-02-22 15:41:40 UTC
When was this supposed to be fixed? Please explain in detail. 
Comment 11 Sergey V. Udaltsov 2007-02-27 04:26:36 UTC
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. 
> 

Comment 12 Helge Hielscher 2007-03-01 01:50:57 UTC
(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.
Comment 13 Sergey V. Udaltsov 2007-03-01 01:58:31 UTC
> 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.
Comment 14 Helge Hielscher 2007-03-01 02:12:10 UTC
(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?
Comment 15 Sergey V. Udaltsov 2007-03-01 02:23:18 UTC
> > 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.
Comment 16 Benjamin Close 2008-01-11 02:37:32 UTC
Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler
Comment 17 Sergey V. Udaltsov 2008-11-26 15:57:31 UTC
Since noone contributed a working patch (and no activity shown), I am closing this one.
Comment 18 Helge Hielscher 2008-11-27 02:52:54 UTC
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. 
Comment 19 Sergey V. Udaltsov 2008-11-27 03:09:59 UTC
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.
Comment 20 Helge Hielscher 2008-11-27 04:22:44 UTC
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.
Comment 21 James Cloos 2008-11-27 05:34:42 UTC
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?
Comment 22 Simos Xenitellis 2008-11-27 05:59:42 UTC
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.
Comment 23 Sergey V. Udaltsov 2008-11-27 06:08:21 UTC
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.
Comment 24 Helge Hielscher 2008-11-27 06:41:21 UTC
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?


Comment 25 Sergey V. Udaltsov 2008-11-27 06:49:25 UTC
Yes, but finding a place for one dead key is less harm than organizing extra levels IMHO.
Comment 26 Helge Hielscher 2008-11-28 06:42:59 UTC
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
Comment 27 Sergey V. Udaltsov 2008-11-28 06:51:30 UTC
Well, there are also shifted numeric ones.
What about changing "Shift-2" (mapped to "Double Quote") to "Dead double acute"?