[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Entering Unicode characters

From: Jean-Christophe Helary
Subject: Re: Entering Unicode characters
Date: Sat, 30 Jan 2016 12:03:12 +0900

> 2016/01/30 1:14、Eli Zaretskii <address@hidden> のメール:
> Can we add an optional feature where the candidates will be shown even
> in deterministic input methods, although the way to choose the
> candidates is not by typing a digit?  For example:
>  a["'/^_`~]  " - ä  ' - á  / - å  ^ - â _ - ª   ` - à  ~ - ã
> or something similar?

The turkish-postfix method seems to offer both, at least with "i".

i[.]         (01/01) 1.ı 2.i

You can get "i" by either typing "." or by typing "1".

For some reason that is not generalized to other characters:

i[.]         (01/01) 1.ı 2.i

For chinese-py, Kenichi proposed "ni":
ni[aenu]  (01/??) 1.你 2.呢 3.尼 4.泥 5.逆 6.倪 7.匿 8.拟 9.腻 0.妮

but since the default is 1, you actually don't have to enter 1 to input 你, and 
similarly, when you go all the way to niang you get 娘 by default and don't need 
to type 1 for input.

The implementation of turkish-postfix for "i" is superior to what we have on 
OSX (if offers discoverability, character based input *and* digit based input) 
but the implementation is not generalized to other letters and other input 
methods and thus is not satisfactory.

My original comment (description of the new OSX input system)  was a reply to 
Richard's request to have a way to view "all the characters" of a given 
language or script:

> I want a system that lets me choose them by seeing them on the screen.
> I want to specify a language or script and see all its characters.
> For instance, if I enter 'turkish' it should show me all the
> characters used in Turkish.  Then I could pick the dotless i from the
> buffer.

Although what I am discussing here is strictly related to current input systems 
and not to a the new capability that Richard desires, I think the bigger issue 
here is first discoverability and then input method.

turkish-postfix offers discoverability for "i". chinese-py offers 
discoverability for all its characters (presumably), neither latin-1-postfix 
not latin-1-prefix offer any sort of discoverability and also lack 
predictability (why does /e= œ but /E=Æ ?, also, when you shift to 
french-prefix you actually do not get all the characters that you could 
possibly type in French - ±÷ªº¥°½¾¼ etc. - even though french should be a 
subset of latin-1, with the exception of œ/Œ.)

Then there is the input method when you have discovered the character you want 
to enter. I personally think that offering 2 options when possible (composing 
character *and* digit) is the best. Composing characters, and in the case of 
chinese-py we can argue that letters *are* composing characters for all 
practical purposes, are available for characters that are input frequently by a 
given user, and digits are there to input the occasional character. There is no 
logical need to not have a digit based input for composed characters.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]