GNU bug report logs -
#43830
keyboard layout handling incompatible with rest of the OS
Previous Next
Full log
Message #95 received at 43830 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> read-event will figure out by itself whether it should return the
> ASCII character or a non-ASCII character, and return that.
I'm not sure that is possible, because it doesn't really know how it
is going to be processed. But you must be much more familiar with
Emacs internals.
Paul
On Sun, 1 Nov 2020 at 18:25, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Sun, 1 Nov 2020 17:51:00 +0100
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 43830 <at> debbugs.gnu.org
> >
> > > > What about functions like `read-event'? It returns integers if I
> press
> > > > M-[letter] or C-[letter].
> > >
> > > read-event is also implemented in C. But maybe I don't understand
> > > your question.
> >
> > I mean, what about the cases where it is called from Elisp? It is
> > implemented in C, but also is publicly available.
> >
> > I have come up with two ideas:
> >
> > 1. `read-event' and its internal C implementation grow an optional
> > parameter that says whether to return character as if being typed (as
> > now) or for keybinding use (i.e. from physical keys).
> >
> > 2. Alternatively, if this cannot be determined in advance (i.e. before
> > calling `read-event' etc.), these functions could set variable named sth.
> > like `last-keybinding-keycode'. Then the caller would use either the
> > return value (as now) or, if it wants, the value of the variable instead.
>
> What I had in mind was
>
> 0. read-event will figure out by itself whether it should return the
> ASCII character or a non-ASCII character, and return that.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 346 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.