[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should this package be included into the NS port?
From: |
Stefan Monnier |
Subject: |
Re: Should this package be included into the NS port? |
Date: |
Sat, 02 Jun 2018 22:25:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> I’m pretty sure that number is the one defined in nsterm.h line 751:
>
> #define KEY_NS_NEW_FRAME ((1<<28)|(0<<16)|12)
Hmm... I wonder why the code uses a number instead of a symbol?
Apparently it's not just specific to NS since system-key-alist is
apparently also used under X11. Here it says:
system-key-alist is a variable defined in ‘keyboard.c’.
Its value is ((65280 . remove))
It is a terminal-local variable; global value is the same.
But AFAIK, this 65280 is an X11 keysym code. I.e. should never be
turned into a Lisp numeric event (since there are only used for
characters).
I guess someone who understands why we have modify_event_symbol might be
able to help us figure out how to best fix this problem.
> and it looks like it’s defined for lisp in x-setup-function-keys in
> common-win.el, but it looks to me like it should be set up in all
> frames where (featurep 'ns) is true.
This code is not run for non-GUI frames/terminals, I think.
> I guess that function doesn’t run on terminal frames, then. That might
> explain it.
Exactly.
> Would we be able to define this (or maybe all of the NS events?) in
> ns-win.el instead of in this function?
Yes.
> Would that be a bad idea?
Seems no worse than having it in common-win.el and
wrapped in (featurep 'ns)
But it might not help, since ns-win.el is used for NS GUI frames,
whereas we'd want it for NS non-GUI frames.
Stefan