Input methods at the age of Unicode

Marcel Schneider charupdate at orange.fr
Sat Jul 18 09:33:23 CDT 2015


On 16 Jul 2015, at 23:59:24 +0100, Eli Zaretskii  wrote: wrote:

> FWIW, I do that a lot, because the number of convenient input methods
> in Emacs far outnumbers what I have on MS-Windows. For example, if I
> have to type Russian with no Russian keyboard available, the
> cyrillic-translit input method is a life savior. 

You might wish also to use the Windows on-screen keyboard which allows to see what's exactly on each key while typing on whatever physical keyboard, without any need to have the keycap labels match the layout. This on-screen keyboard is built-in, only it does not support Kana shift states.
Likewise Windows came to me along with all that is needed to type Ἐν ἀρχῇ ἦν ὁ λόγος, so I canʼt really believe that users need Emacs as a savior. 

When process garbage is an environmental issue, one might consider that our real savior is Notepad++, thanks to its energy saving algorithms. Indeed I do not think that we should get supplemental input facilities at any price. This is why, too, the goal should be to pack a reasonably large subset of Unicode into the very core of the keyboard driver of every locale, and make it accessible right there with a Compose tree. Every time we open charmap dialogs or even go on the internet to pick a character, weʼre consuming some energy, and if itʼs a routine task that could be done with a memorized Compose sequence, that energy is wasted. I donʼt know if itʼs a real issue, but Iʼm likely to believe it is.

Of course we need some software as a savior, but this software is consequently called Zotero and helps us save and manage our research results (“Search, not re-search!” https://www.zotero.org).

Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150718/c0e703da/attachment.html>


More information about the Unicode mailing list