Created attachment 24536 [details] [review]
Combining accents variant for rs.
In bug #21044, some accents were added to Cyrillic variants as dead keys.
Given that almost all letters producable by these accents will be combined
in output (no NFC counterparts), it was not immediately obvious whether to
use dead keys or raw combining characters to type them. We had a small
discussion on that here (in Serbian):
The outcome was that it's better to use dead keys, for no other reason but
that it seems to be the de-facto standard of typing accented letters (when
they are not available as single keystroke), and thus the path of least
surprise. So that's what patch in bug #21044 did.
However, when compared on equal basis, the discussion above did identify an
advantage of combining over dead key solution. (Identified = I proposed,
noone disputed.) This advantage stems from what the accents represent and
how they are used in Serbian language (I'll repeat a bit from the recent
discussion on the mailing list, to round up the report).
Unlike the diacritics making standard appearance or defining standalone
letters and different voices, e.g. French ç or German ü, accent diacritics
in Serbian Cyrillic are used solely to convey pronunciation stress. In
general literature this is used only as necessary, e.g. when two words
pronounced with different stress appear same in writing, so as to
disambiguate the meaning if not obvious from context; and then the accent is
added only on the less frequent of the two words, e.g. код = at, ко̑д =
code. Accents are rarely used throughout, e.g. in dictionaries to show the
pronunciation stress for each entry.
This practically means the following: it is quite normal for one, e.g.
reviewer of the text, to add accents along the way where needed, when the
original author didn't. Similarly if one needs to accent every word in a
given sentence (school exercise, pronunciation note, etc.) This is quite
unlike when diacritics make up basic ortography, e.g. there would not be a
straigh-faced German text through which someone should hunt for ä, ö, ü with
missing diaresis (the writer would have to be rather illiterate to omit
them, so the text wouldn't exist in the first place). So, if accents are to
be post-added, it's more efficient and less typo-prone to just place the
cursor and hit combining accent, then to delete the letter, hit dead accent,
hit same letter again.
(I also wonder of how the diacritic-then-letter typing order came by at all,
as when we write by hand, in every language I've seen it's the letter that
gets written first, and then the diacritic added. A guess would be that it
was taken on from typesetting systems with pre/infix notation, like Latex,
where a diacritic was effectively a command and letter followed as its
So the patch simply adds a "combiningkeys" variant, with dead keys replaced
by combining characters, for those who are into post-accenting (I e.g. do it
when reviewing translations), or simply never got used to diacritic-then-
letter order and letter-then-diacritic seems more natural. The dead
circumflex is retained on the fourth level though, to be able to type
composed number exponents (for the update in bug #21044, at start I also
intended to add first few exponents, for "squared", "cubed", but then
realized compose sequences with dead circumflex do the job just fine).
I thought whether to name the variant "nodeadkeys", but the proposed
modification doesn't really seem to me analogous to what nodeadkeys means in
I do realize that no other layout uses raw combining diacritics, so if the
above rationale doesn't cut it, a one-liner "thanks, but no thanks" will do
just fine, no need to waste time explaining in more detail :)
I thought about your idea for quite a while. In Russian, we have similar practice of using diacritics for stressing vowels (for schools, dictionaries etc), so I understand what you want to achieve.
But I guess it is too exotic to included in the mainstream.
What xk-c is missing is some kind of "contrib" section, where we could keep layouts like that. But ATM I do not know what would be the proper maintenance scheme. If you have any ideas or proposals - we could discuss it here or in the maillist or on IRC...
I like the idea of a "contrib" section, that is if I have the same thing in
mind: a collection of layouts for which it can hardly be expected to be of
widespread use, but can be argued that a certain group of people may find
them useful. For example, aside from my proposal here, for Serbian layouts
we've had people asking for "minimum-deviation" layout to US (programmers),
for IPA counterparts to our alphabets on third level (linguists), non-
Serbian Cyrillic characters on third level of Cyrillic variants (speakers of
Russian)... Heck, I'd even move several of the existing variants of Serbian
layout into such contrib section.
I think the mailing list would be a good place to discuss it, so you could
start a thread there if you have a kernel of idea of how "contrib" would be
technically managed. I don't have any right now (also don't know what are
the basic assumptions, e.g. is contrib supposed to be released as a separate
welcome 2 discussion in the blocker bug
Fixed in git, into "extras" section.
For the last few days I was a bit short on time to react after the
introduction of the extras section, so now I can only say -- great, thanks!
What I'm wondering is what about moving some of the earlier rs variants to
extras? Would that cause too much trouble? Out of current 8, I'd move 4 to
extras. (Of course, opening separate but report for the patch...)
> For the last few days I was a bit short on time to react after the
> introduction of the extras section, so now I can only say -- great, thanks!
You're welcome. Thanks to you - you (and some other bug reports) made me finally make the step I was going to do for quite a while;)
> What I'm wondering is what about moving some of the earlier rs variants to
> extras? Would that cause too much trouble? Out of current 8, I'd move 4 to
> extras. (Of course, opening separate but report for the patch...)
Technically, it should be is easy. Yes, a separate bug for that move would be needed.