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): http://www.vokabular.org/forum/index.php?topic=3569.0 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 argument...) 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 other layouts. 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 package?)
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.
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.