bug#38007: scroll-lock binding on Windows

bug#38007: scroll-lock binding on Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

This is with 27.0.50, on Windows 10.

The binding of scroll-lock-mode on binding.el is:

  (define-key global-map [Scroll_Lock]    'scroll-lock-mode)

and the docstring of scroll-lock-mode says:

  Note that the default key binding to Scroll_Lock will not work on
  MS-Windows systems if ‘w32-scroll-lock-modifier’ is non-nil.

And the default value of w32-scroll-lock-modifier is nil:

  w32-scroll-lock-modifier is a variable defined in ‘C source code’.
  Its value is nil

But the Scroll Lock key does not generate a Scroll_Lock event, but scroll:

  <scroll> is undefined

Shouldn't the binding be to [scroll] on Windows?

[-- Attachment #2: Type: text/html, Size: 898 bytes --]

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Oct 2019 18:46:43 +0100
> 
> Shouldn't the binding be to [scroll] on Windows?

Yes, I think so.

bug#38007: scroll-lock binding on Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Thu, Oct 31, 2019 at 7:07 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Shouldn't the binding be to [scroll] on Windows?
>
> Yes, I think so.

OK. I see three ways:

- Something like this in bindings.el:

(define-key global-map (if (eq system-type 'windows-nt) [scroll]
[Scroll_Lock]) 'scroll-lock-mode)

- Leave bindings.el as is and rebind the command to [scroll] in
lisp/term/w32-win.el,

- Or use some of the translation keymaps to translate [scroll] into
[Scroll_Lock].

Which one makes more sense?

[-- Attachment #2: Type: text/html, Size: 762 bytes --]

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Oct 2019 23:59:45 +0100
> Cc: 38007@debbugs.gnu.org
> 
> OK. I see three ways:
> 
> - Something like this in bindings.el:
> 
> (define-key global-map (if (eq system-type 'windows-nt) [scroll] [Scroll_Lock]) 'scroll-lock-mode)
> 
> - Leave bindings.el as is and rebind the command to [scroll] in lisp/term/w32-win.el,
> 
> - Or use some of the translation keymaps to translate [scroll] into [Scroll_Lock].
> 
> Which one makes more sense?

I don't know yet, because I don't see where does Scroll_Lock come on
Posix platforms.  Can someone tell what did I miss?

bug#38007: scroll-lock binding on Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On Fri, Nov 1, 2019 at 7:17 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I don't know yet, because I don't see where does Scroll_Lock come on
> Posix platforms.  Can someone tell what did I miss?

No answer after almost two weeks. Perhaps we should bring it to emacs-devel?

[-- Attachment #2: Type: text/html, Size: 382 bytes --]

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

On November 13, 2019 4:50:00 PM GMT, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Nov 1, 2019 at 7:17 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I don't know yet, because I don't see where does Scroll_Lock come on
> > Posix platforms.  Can someone tell what did I miss?
> 
> No answer after almost two weeks. Perhaps we should bring it to
> emacs-devel?

Please do, and thanks.

bug#38007: scroll-lock binding on Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

No answer in Emacs devel after nine days.

So I'l fix it for Windows somehow.

Which alternative do you prefer:

- conditionally binding it to [scroll] in bindings.el according to
system-type

- rebinding it in term/w32-win.el,

- or remapping [scroll] to [Scroll_Lock] in some special keymap (perhaps
function-key-map?)

[-- Attachment #2: Type: text/html, Size: 448 bytes --]

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 22 Nov 2019 10:06:11 +0100
> Cc: 38007@debbugs.gnu.org
> 
> - conditionally binding it to [scroll] in bindings.el according to system-type
> 
> - rebinding it in term/w32-win.el,
> 
> - or remapping [scroll] to [Scroll_Lock] in some special keymap (perhaps function-key-map?)

The former, with a comment about the (evidently unknown) source of the
Scroll_Lock "function key".

Thanks.

bug#38007: scroll-lock binding on Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Fri, Nov 22, 2019 at 10:16 AM Eli Zaretskii <eliz@gnu.org> wrote:

> The former, with a comment about the (evidently unknown) source of the
> Scroll_Lock "function key".

AFAICS, the X Window System Protocol (
https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html) defines the
keysyms as numeric codes with a conventional name, in this case

#xFF14   SCROLL LOCK

which is represented in /usr/include/X11/keysymdef.h as

#define XK_Scroll_Lock                   0xff14

but I don't know how that is converted into a keyboard event.

[-- Attachment #2: Type: text/html, Size: 823 bytes --]

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 22 Nov 2019 10:44:55 +0100
> Cc: 38007@debbugs.gnu.org
> 
> AFAICS, the X Window System Protocol (https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html)
> defines the keysyms as numeric codes with a conventional name, in this case 
> 
> #xFF14   SCROLL LOCK
> 
> which is represented in /usr/include/X11/keysymdef.h as
> 
> #define XK_Scroll_Lock                   0xff14
> 
> but I don't know how that is converted into a keyboard event.

Yes, the latter is the missing piece.  Maybe put all of the above into
that comment.

bug#38007: scroll-lock binding on Windows

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> - conditionally binding it to [scroll] in bindings.el according to system-type
>> 
>> - rebinding it in term/w32-win.el,
>> 
>> - or remapping [scroll] to [Scroll_Lock] in some special keymap
>> (perhaps function-key-map?)
>
> The former, with a comment about the (evidently unknown) source of the
> Scroll_Lock "function key".

I've now done the former in Emacs 29, but I don't quite understand why
the Scroll_Lock event needs a comment -- it's just a normal X keyboard
event, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  38007@debbugs.gnu.org
> Date: Mon, 07 Feb 2022 04:58:27 +0100
> 
> > The former, with a comment about the (evidently unknown) source of the
> > Scroll_Lock "function key".
> 
> I've now done the former in Emacs 29, but I don't quite understand why
> the Scroll_Lock event needs a comment -- it's just a normal X keyboard
> event, I think?

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.

bug#38007: scroll-lock binding on Windows

[Lars Ingebrigtsen]

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.  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.

I thought that was the conclusion the last time keyboard events was
discussed, but my memory may well be faulty.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38007: scroll-lock binding on Windows

[Andreas Schwab]

On Feb 08 2022, Lars Ingebrigtsen wrote:

> Oh, I see.  No, I don't know where it's coming from.  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.

See get_keysym_name.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  lekktu@gmail.com,  38007@debbugs.gnu.org
> Date: Tue, 08 Feb 2022 10:07:09 +0100
> 
> On Feb 08 2022, Lars Ingebrigtsen wrote:
> 
> > Oh, I see.  No, I don't know where it's coming from.  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.
> 
> See get_keysym_name.

Thanks!

bug#38007: scroll-lock binding on Windows

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: lekktu@gmail.com,  38007@debbugs.gnu.org
> Date: Tue, 08 Feb 2022 07:06:45 +0100
> 
> 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.  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.
> 
> I thought that was the conclusion the last time keyboard events was
> discussed, but my memory may well be faulty.

Maybe.  I simply don't know, and was quite bewildered at the time.

bug#38007: scroll-lock binding on Windows

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.