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

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

bug#67430: 29.1; <Multi_key> is undefined


From: Francesco Potortì
Subject: bug#67430: 29.1; <Multi_key> is undefined
Date: Sat, 25 Nov 2023 14:18:54 +0100

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: pot@gnu.org,  67430@debbugs.gnu.org
>> Date: Sat, 25 Nov 2023 19:10:15 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > What other roles does this key play?  And how frequent is each role?
>> 
>> I don't know.  There is generally no other use for it under X, except
>> perhaps as a modifier key, which if true Emacs won't register key
>> presses at all.
>> 
>> > Also, if we bind this key by default as Francesco suggests, what
>> > adverse results could this cause on the systems where this binding is
>> > wrong?
>> 
>> Nothing beyond the obvious, to wit: Emacs will react to pressing the
>> Multi_key as though it were bound to iso-transl-ctl-x-8-map.
>
>Then maybe we should behave by default as Francesco suggested?  users
>which don't like the results could always unbind/rebind the key.
>WDYT?

In mormal usage, Emacs never even sees <Multi_key>.  I suppose that Emacs, like 
usual X applications, relies on X to interpret it as a modifier key, and X uses 
its composition rules.  But Xpra apparently is another piece of cake (at least 
the version I am using) and it passes the key as-is.  I think that this is 
unusual behaviour.

If Emacs happens to see <Multi_key>, maybe in principle it should ask X to 
interpret the subsequent characters using X's composition rules.  I don't know 
if that's possible in a clean way, I suppose that would not be obvious to do.  
Lacking such functionality, I think the only reasonable thing to do is to 
interpretet is as C-x 8, which has composition rules mostly compatible with 
those of X.  So in most cases this will be transparent to the user.  I don't 
see how throwing an error instead can be better.  And yes, in principle users 
can rebind it.

An alternative would be to bind <Multi_key> to a command which is disabled by 
default (like for example narrow-to-page), and when enabled does the same as 
C-x 8.  But I think that binding it by default is simpler and has so rare and 
technical drawbacks that people caring it about are aware of the issue and can 
solve it.





reply via email to

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