[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38007: scroll-lock binding on Windows
From: |
Po Lu |
Subject: |
bug#38007: scroll-lock binding on Windows |
Date: |
Tue, 08 Feb 2022 22:09:25 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Did you succeed in figuring out where does the "Scroll_Lock" text come
>> from? It isn't in lispy_function_keys[] array. On MS-Windows,
>> "scroll" does come from that array. That's what I meant by that
>> remark.
>
> Oh, I see. No, I don't know where it's coming from.
It's from get_keysym_name in xterm.c.
> I thought that we (under X) got the key symbols for (some) keys from
> X, and didn't maintain the database ourselves? So we can basically
> get any symbol that the X people dream up.
Yes, and that database is huge. "Some" of those symbols have to be
treated specially; see the big block of code under KeyPress and
XI_KeyPress in handle_one_xevent that tries to handle the most common
ones might run across. It starts with:
/* Random non-modifier sorts of keysyms. */
if (((keysym >= XK_BackSpace && keysym <= XK_Escape)
|| keysym == XK_Delete
That list is hardly exhaustive, and a few new keysyms were added
recently that I haven't gotten around to looking at yet.