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

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

bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and


From: Kévin Le Gouguec
Subject: bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
Date: Fri, 24 Jun 2022 07:58:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

(Taken off-list because I'd rather limit the noise; I'm very likely
missing something)

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> And there's absolutely no way for Emacs to get at the original keys?
>
> It can by turning the input method off, but as a result any features
> provided by them will no longer work.

I'm a bit confused by that statement; you may remember that silly
experiment I ran in bug#52795?

https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;msg=17;filename=goof.patch;bug=52795

Po Lu <luangruo@yahoo.com> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> AFAICT Emacs receives enough information to see S-SPC?
>
> Yes, but after going through an input method module the S-SPC is lost.
>
>> No idea how easy it would be to pass on that information to the rest
>> of Emacs.
>
> Not easy, if we want to keep input methods (which GTK uses to implement
> the compose key) working.

At the time that left me with the impression that in principle, Emacs
could record what it received before "going through an input method" and
recover the lost information after the input method did its (bad) job;
in practice I assume that would be a very horrible kludge and a
nightmare to maintain.

Was that impression correct?  I'm not pushing for such a kludge; just
wondering if it's in the realm of possibility.





reply via email to

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