[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-ASCII chars in quail rules

From: Perry E. Metzger
Subject: Re: Non-ASCII chars in quail rules
Date: Sat, 30 Aug 2014 18:48:44 -0400

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

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 E. Metzger                address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]