From mboxrd@z Thu Jan  1 00:00:00 1970
From: dmr@plan9.bell-labs.com
Message-Id: <200006190720.DAA15444@cse.psu.edu>
Subject: Re: [9fans] input methods, how?
Date: Mon, 19 Jun 2000 03:20:26 -0400
To: 9fans@cse.psu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: c3c239ec-eac8-11e9-9e20-41e7f4b1d025

This is about the asian-language input question--

  Q:  Is there some way I can use namespaces or something to just filter =
what is
  read from /dev/console (not replace that service altogether,  hopefully=
).  So I
  want to stack a "stream filter" on top of /dev/console (just for readin=
g),  I
  think.  Is there any such thing?

Russ's answer began=20
  Sure.  If you require that rio be run on top of it,
  then you can make it very simple; in particular
  you wouldn't need to worry about writes to
  /dev/cons or about flush messages.  Just take
  characters as they come in from the real /dev/cons
  repackage them, and use them to satisfy read
  requests.

It is pretty easy to write a 9P server suitable for binding
over /dev/cons that translates things coming from the
keyboard, if you're willing to start it, bind it to
/dev/cons, and redirect IO in a new window.  This
is definitely the way to do experiments with
the algorithm.

Doing it in such a way that it doesn't lead to
implementation artifacts is harder.  cons will=20
certainly have to be in raw mode, and will have
to think about signals (notes), both to generate
them and respond to them appropriately, and the
raw mode means it will need to do the line-editing
and echoing if it is running a particular window.

One possible approach to this is to do it as Russ says,
a filter that runs underneath the window system
itself, to take advantage of the code that is already
in rio.  A disadvantage is that the program then
has no notion of the windows--e.g. if you have
a partial sequence composing a character
and switch windows, or want to do different
languages in different windows, things will get
confused.  The program will of necessity have
a global, not per-window state. I suppose one of the
keyboard characters could throw up a menu to show
and communicate changes in the global state.

In the earlier window system, 8=C2=BD, I added a new
/dev/kbd device (private to each window,
much as /dev/cons is) such that after a program opened kbd
in a window, 8=C2=BD sent its own input characters for that
keyboard-focus window to its own internal device, whence
they could then be read by that instance of /dev/kbd.  Writes
(by the program) on its /dev/kbd were then re-inserted by
the device back into 8=C2=BD's input stream for the window.

This worked fairly reliably, but it wasn't redone
for rio.

For simple translations like "ascii" keyboard to dvorak
as discussed more recently, a kernel mapping might
be the line of least resistance.  For much more
complicated things, like Asian-language handling
requiring substantial dictionaries, a user-mode solution
seems much better.

Maybe I'm having a failure of vision, but making this all
work right seems not entirely trivial.

	Dennis