Why UTF-8/16 character encodings?

[H. S. Teoh]

On Mon, May 27, 2013 at 04:17:06AM +0200, Wyatt wrote:
> On Sunday, 26 May 2013 at 21:23:44 UTC, H. S. Teoh wrote:
> >I have been thinking about this idea of a "reprogrammable keyboard",
> >in that the keys are either a fixed layout with LCD labels on each
> >key, or perhaps the whole thing is a long touchscreen, that allows
> >arbitrary relabelling of keys (or, in the latter case, complete
> >dynamic reconfiguration of layout). There would be some convenient
> >way to switch between layouts, say a scrolling sidebar or roller dial
> >of some sort, so you could, in theory, type Unicode directly.
> >
> >I haven't been able to refine this into an actual, implementable
> >idea, though.
> >
> I've given this domain a fair bit of thought, and from my
> perspective you want to throw hardware at a software problem.  Have
> you ever used a Japanese input method?  They're sort of a good
> exemplar here, wherein you type a sequence and then hit space to
> cycle through possible ways of writing it.  So "ame" can become,
> あめ, 雨, 飴, etc.  Right now, in addition to my learning, I also
> use it for things like α (アルファ) and Δ (デルタ).  It's limited,
> but...usable, I guess.  Sort of.
> 
> The other end of this is TeX, which was designed around the idea of
> composing scientific texts with a high degree of control and
> flexibility.  Specialty characters are inserted with
> backslash-escapes, like \alpha, \beta, etc.
> 
> Now combine the two:  An input method that outputs as usual, until
> you enter a character code which is substituted in real time to what
> you actually want.
> Example:
> "values of \beta will give rise to dom!" composes as
> "values of β will give rise to dom!"
> 
> No hardware required; just a smarter IME.  Like maybe this one:
> http://www.andonyar.com/rec/2008-03/mathinput/ (I'm honestly not yet
> sure how mature or usable that one is as I'm a UIM user, but it does
> serve as a proof of concept).

I like this idea. It's certainly more feasible than reinventing the
Optimus Maximus keyboard. :) I can write code for free, but engineering
custom hardware is a bit beyond my abilities (and means!).

If we go the software route, then one possible strategy might be:

- Have a default mode that is whatever your default keyboard layout is
  (the usual 100+-key layout, or DVORAK, whatever.).

- Assign one or two escape keys (not to be confused with the Esc key,
  which is something else) that allows you to switch mode.

   - Under the 1-key scheme, you'd use it to begin sequences like \beta,
     except that instead of the backslash \, you're using a dedicated
     key. These sequences can include individual characters (e.g.
     <ESC>beta == β) or allow you to change the current input mode (e.g.
     <ESC>grk to switch to a Greek layout that takes effect from that
     point onwards until you enter, say, <ESC>eng). For convenience, the
     sequence <ESC><ESC> can be shorthand for switching back to whatever
     the default layout is, so that if you mistype an escape sequence
     and end up in some strange unexpected layout mode, hitting <ESC>
     twice will reset it back to the default.

   - Under the 2-key scheme, you'd have one key dedicated for the
     occasional foreign character (<ESC1>beta == β), and the second key
     dedicated for switching layouts (thus allowing shorter sequences
     for switching between languages without fear of conflicting with
     single-character sequences, e.g., <ESC2>g for Greek).

Perhaps the 1-key scheme is the simplest to implement. The capslock key
is a good candidate, being conveniently located where your left little
finger is, and having no real useful function in this day and age.

The only drawback is no custom key labels. But perhaps that can be
alleviated by hooking an escape sequence to toggle an on-screen visual
representation of the current layout. Maybe <ESC>? can be assigned to
invoke a helper utility that renders the current layout on the screen.


T

-- 
Don't get stuck in a closet---wear yourself out.