Re: composed characters question and suggestions for quail-cyrillic-*

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 09 Jul 2008 22:33:38 +0300 Juri Linkov <juri@jurta.org> wrote: 

TZ> OK, I changed things accordingly and will commit to CVS when the problem
TZ> above with doing combining characters in Quail is resolved.
>> 
>> This is the only thing stopping me.  I adjusted the accents and added
>> some more special characters; here's the special characters with some
>> comments.
>> 
>> ("/c" ?©)
>> ("/tm" ?®) ;; I couldn't find a TM glyph in Unicode

JL> It is ?\u2122.

JL> It is ?\u2122.

OK, I changed to:

 ("/tm" ?™)
 ("/reg" ?®)

>> ("/kop" ?к) ;; not sure

JL> No Unicode character, and never will be I guess.

Probably not worth the trouble then.  Same for rubles, leva, and
stotinki, their symbols are currently trivial so I'll remove them.

The situation is different for Roman numerals which have distinct code
points from the corresponding ASCII characters.  I'm not including
lowercase versions but I could (downcase-region is so nice, this took 2
seconds):

 ("/i" ?ⅰ)
 ("/ii" ?ⅱ)
 ("/iii" ?ⅲ)
 ("/iv" ?ⅳ)
 ("/v" ?ⅴ)
 ("/vi" ?ⅵ)
 ("/vii" ?ⅶ)
 ("/viii" ?ⅷ)
 ("/ix" ?ⅸ)
 ("/x" ?ⅹ)
 ("/xi" ?ⅺ)
 ("/xii" ?ⅻ)

I don't recall them being used for anything, but then again it's been a
while since I wrote in Bulgarian every day, and Russian and others may
want them.

>> I often see it written as q or u in manually transliterated text.  Maybe
>> // or /q or /u would work?  The corresponding /? /Q /U would uppercase it.

JL> I've never seen it written as q or u.  And indeed there is no such rule
JL> on http://en.wikipedia.org/wiki/Translit or on this page in other
JL> languages (Bulgarian, Russian) where q is used for ю, and q for я.

It's ad hoc I guess.  No matter.

JL> One possible letter for ь is x.  I guess it is from jcuken-only
JL> keyboards, but since it is already taken for x in cyrillic-translit,
JL> maybe we should replace the rule ("x" ?х) with ("x" ?ь)?

OK, ditto for X -> Ь.  We'll be lynched, surely.

JL> I like your current set of rules, they are easy to remember and input.
JL> But I have doubts about << and >> since they are inconsistent with
JL> other sequences with the leading slash.

Yes, but it's very rare to need << or >> in any other context.  Let's
try it, I'm sure only shell users will complain :)  At worst you have to
do

C-\ Shift-, Shift-, C-\ 

to get the regular << meaning.  Compared to 

/ Shift-, Shift-,
/ Shift-. Shift-.

all the time while typing, I think it's better.

JL> Since these rules will be needed in parallel with other input methods,
JL> I suggest you to create two separate input methods: one with the name
JL> like `typographic' (if you are going to provide only typographic
JL> characters) for rules without the leading slash and `typographic-pre'
JL> for rules with the leading slash.  And with the code Handa-san provided
JL> it will be possible to activate multiple input methods.

When that code is in the CVS trunk I can do that, but I'm not convinced
having two methods (with/without prefix) would be any better than a
single common one.  A single method means less to remember, less to
confuse the user.

JL> Then how about the following rules:

JL> /.	"․" U2024 # ONE DOT LEADER
JL> /..	"‥" U2025 # TWO DOT LEADER
JL> /...	"…" ellipsis # HORIZONTAL ELLIPSIS

Added also.

Ted