emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: poor additions in quail/latin-ltx


From: Stefan Monnier
Subject: Re: poor additions in quail/latin-ltx
Date: Sun, 13 Mar 2005 11:02:25 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> What I currently see in my Lucid menu is a question mark.  Is that what you
>> mean by "junk"?

> No, I meant basically random characters.  Question marks would be
> better.  Maybe something has changed; I can't check at present.  I
> can't remember how it is (or was) and what cleanup was rejected, but I
> think the encoding of text sent to the menus was wrong, at least.

Oh, now I see: my local hacked Emacs got question marks, but that was
a side-effect of a local change (I redefine make_string_unibyte to do
(encode-coding-string str locale-coding-system)),

>> Or maybe it depends on your locale and other Mule settings.
>> In any case, it would be great to get utf-8 support in the Lucid menu, even
>> if it's only when you're running under a utf-8 locale.

> If it worked, it would depend on the locale, the fonts used, and how
> coding conversion was done.  I wrote something about it on TODO.

See the patch I sent on this list yesterday.

>> How 'bout the patch below to maths-menu.el (which also fixes your code so
>> you get paren-matching when inserting a paren-like char).

> I think it would be best to fix tmm to DTRT and fix the menu code so
> that you can bind a string as a command like you'd expect.  (The idea
> was to make this effectively, or actually, an input method.)  The
> error message you get binding a string is clearly wrong, at least.

Hmmm you seem to be talking about "why the code used a lambda rather than
a string".  This seems unrelated to tmm.  It should be fixed indeed, but
I have no time to look into it.

The problem with tmm is that it uses the menu entry's first char as "the key
to hit to select the entry".  But this doesn't work well in case where you
don't know how to input this char.  We could restrict tmm to only use ASCII
chars for those things, but it might be inconvenient in some cases.

But the change I posted (which basically moves the unicode char to the end
of the entry's text) works as well and I think putting the char in the
"short cut key" section makes a lot of sense regardless of the problem
w.r.t tmm.

> Anyway it's moot if rms won't accept multilingual menus.

I don't know what you're referring to.  I can't remember Richard rejecting
the idea of multilingual menus.


        Stefan




reply via email to

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