GNU bug report logs - #60711
Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

Previous Next

Package: emacs;

Reported by: Marcin Kasperski <Marcin.Kasperski <at> mekk.waw.pl>

Date: Tue, 10 Jan 2023 15:14:02 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 60711 <at> debbugs.gnu.org, Marcin Kasperski <Marcin.Kasperski <at> mekk.waw.pl>
Subject: bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)
Date: Tue, 17 Jan 2023 08:41:12 +0800
Gregory Heytings <gregory <at> heytings.org> writes:

> What do you mean?  Conceptually the code does this:
>
> while (XPending (display))
>   {
>     XNextEvent (display, &event);
>     if (XFilterEvent (&event, None) == True)
>       continue;
>     if (event.type == KeyPress)
>       {
>         XmbLookupString(input_context, &event.xkey, buffer, sizeof (buffer) - 1, &keysym, &status);
>         if (status == XLookupChars)
>           {
>             /* do something with buffer */
>           }
>       }
>   }
>
> There is nothing that must be kept around in that code.

Where do you think the text that is stored in buffer comes from?  And
what if the input method choses to commit a keysym?

What if the Xlib character encoding routines do not understand that
particular character?

> I'm sure there are possible complications, but AFAIU they do not
> change the pattern outlined above.

If you get XLookupChars, then half the time the key event you receive is
not a real key event.  Many things can go wrong there, so it is
impossible to debug this without knowing exactly what events are being
sent.




This bug report was last modified 2 years and 101 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.