bug#43830: keyboard layout handling incompatible with rest of the OS

[Paul Pogonyshev <pogonyshev@gmail.com>]

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

> It knows the binding of the character, and it knows other things.

When it knows the bindings (99% of cases) it is called internally by
the command loop, so it doesn't even go into Elisp domain here.
If something calls `read-event' or similar on the Elisp level,
presumably they don't use keymaps for whatever reasons and
process events specially. In this case `read-event' cannot possibly
know what The Right Thing is.

> Nothing else makes sense to me, because exposing this info to Lisp
> means every Lisp program which deals with input will have to decide
> what to do with such events.

As I understand it, 99% of handling is done by the main command
loop at the C level, so it is not a problem to do it once there. I still
would give Elisp access so that special users of `read-event' etc. can
follow suit, but this would not oblige them to do anything. Programs
and modes that don't do anything special (either because they are
old or do not care) will just behave as now, with no effective changes.

Paul

On Sun, 1 Nov 2020 at 20:33, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Paul Pogonyshev <pogonyshev@gmail.com>
> > Date: Sun, 1 Nov 2020 19:56:09 +0100
> > Cc: Juri Linkov <juri@linkov.net>, 43830@debbugs.gnu.org
> >
> > > 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.
>
> It knows the binding of the character, and it knows other things.
>
> Nothing else makes sense to me, because exposing this info to Lisp
> means every Lisp program which deals with input will have to decide
> what to do with such events.
>

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