Re: Non-ASCII chars in quail rules

[Perry E. Metzger]

On Fri, 29 Aug 2014 21:13:39 -0400 Stefan Monnier
<address@hidden> wrote:
> > 1) Is there any easy way to fix that? Simply removing the < 127
> > test in the code that builds the maps doesn't work. (I'm afraid I
> > don't fully understand where the maps are used, which is probably
> > a problem.)
> 
> AFAIK there is no technical reason for the <127 limit.  So I think
> the best way forward is to remove the <127 test and then see what
> breaks next, fix that part, lather, rinse, repeat.
> 
> If you have trouble with the "fix that part", feel free to send us
> a recipe to reproduce the problem (probably includes your
> work-in-progress-patch) so we can help along.

I've been digging in to this and it isn't nearly as simple as I
thought. As I suspected, it isn't just the test.

Part of the issue is that the whole of quail seems to be driven off
of things arriving via the set input-method-function, and function
key inputs and the like don't end up flowing through
input-method-function at all.

(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.)

I think I'll dig at it for a while longer. What I want might require
adding an alternative path to start invoking quail's substitution
behavior, or it might be better if I ignore the input method
machinery entirely.

Perry
-- 
Perry E. Metzger                address@hidden