Re: Non-ASCII chars in quail rules

["Perry E. Metzger" <perry@piermont.com>]

On Sun, 31 Aug 2014 08:38:24 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > (Indeed, input-method-function seems to be restricted to passing
> > along information about printable ASCII (or at least, it
> > documents itself as only dealing with octal 040 to 0176), and
> > directly via read-char/read-event.)
> 
> There's no doubt that it won't work for function keys under a tty
> (where those function keys are transmitted as "escape sequences",
> which Emacs translated back into "function key" via
> input-decode-map which happens *after* input decoding).
> 
> Maybe it could be made to work for that case as well, but for now
> I think we should focus on the GUI case, where those problems
> shouldn't appear.

Well, for either case, it should be possible to make this work by
pushing back the event into the event queue:

(setq unread-command-events (listify-key-sequence [...])))

which I turned into a function and bound to F19. (I substituted the
unicode value for the compose codepoint in where the ... are in that
sample). The unicode value then does arrive back via
input-method-function

I also then manually bound that value to quail-self-insert-command in
the appropriate quail keymaps, and yet everything isn't working right
for me even yet. I think I'm close, though.

> > I think I'll dig at it for a while longer.
> 
> Do you have a recipe to reproduce your current problem?

I'll construct a minimized version of it and forward that later today.

One overall note: this area of emacs is *really* not documented very
well, which makes the problem a lot harder for someone unfamiliar
with it who starts digging in.

-- 
Perry E. Metzger		perry@piermont.com