[9fans] input methods, how?

[9fans] input methods, how?

[Stephen Harris]

Congrats on Plan9 and its open source release!

I've done an asian-language input method which I'd like to port to plan9.

I need to eat keystrokes until I've got enough to form a character (or an
error), then deliver the composite character to the focused application.

I'd like to not have to compile this stuff into the applications themselves, of
course.

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 reading),  I
think.  Is there any such thing?

Thoughts? Better way?

- Steve Harris

Re: [9fans] input methods, how?

[dmr]

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 reading),  I
  think.  Is there any such thing?

Russ's answer began 
  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 
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½, 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½ 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½'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

Re: [9fans] input methods, how?

[rsc]

  I need to eat keystrokes until I've got enough to form a character (or an
  error), then deliver the composite character to the focused application.

  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 reading),  I
  think.  Is there any such thing?

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.  Two procs working side-by-side would
work quite well.  Have a look at /sys/src/cmd/authfs.c,
which is probably close to what you would need
(ignore all the weird authentication code at the top).

Russ