From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#43830: keyboard layout handling incompatible with rest of the OS Date: Sun, 1 Nov 2020 21:06:50 +0100 Message-ID: References: <87h7r78a5y.fsf@mail.linkov.net> <87imbn2iwm.fsf@mail.linkov.net> <87y2kisawy.fsf@mail.linkov.net> <83362qa073.fsf@gnu.org> <87blhdrhww.fsf@mail.linkov.net> <83362p85l3.fsf@gnu.org> <83y2jqcrvn.fsf@gnu.org> <87blghbjpn.fsf@mail.linkov.net> <83blghf0rf.fsf@gnu.org> <83v9eoeuud.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000465cf705b3112c6e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20992"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43830@debbugs.gnu.org, Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 01 21:10:02 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kZJft-0005Lh-Mj for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 21:10:01 +0100 Original-Received: from localhost ([::1]:59628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZJfs-0001mr-PX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 15:10:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZJdy-0001Ak-90 for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZJdx-0007Mx-Vb for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:08:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZJdx-0002gK-PS for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Nov 2020 20:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43830 X-GNU-PR-Package: emacs Original-Received: via spool by 43830-submit@debbugs.gnu.org id=B43830.160426123010250 (code B ref 43830); Sun, 01 Nov 2020 20:08:01 +0000 Original-Received: (at 43830) by debbugs.gnu.org; 1 Nov 2020 20:07:10 +0000 Original-Received: from localhost ([127.0.0.1]:38659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZJd7-0002fG-VY for submit@debbugs.gnu.org; Sun, 01 Nov 2020 15:07:10 -0500 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:54112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZJd6-0002f1-1F for 43830@debbugs.gnu.org; Sun, 01 Nov 2020 15:07:08 -0500 Original-Received: by mail-wm1-f51.google.com with SMTP id p22so7464518wmg.3 for <43830@debbugs.gnu.org>; Sun, 01 Nov 2020 12:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7PDLVJWJwvLrwfmKZw+n93ZjsWj5RspN5aikLjksBOg=; b=iR+qfLaaUWIXLOoY4llOGqghS1OGQlfffYFZED5CTClBCOTyFuZOUaiZvoioKlTfRQ 42rOv9NXipUH2mRvmowrYIhNzGVHVfDoTK+pcrsJjH9rShVXjEkJ3yjWnwPuSjAazT75 uTqeHnp8aDBoPatvE1bI+T7YMtwTR6WDel6mACLNdCQL+PVtQCjQozHflBsxh61yi8YU WHB8w6CBAoV3TcsWrH9Y76m1EMkfNF5fdBsysRYTixKzZuRpFqLPjiBXDIQBhNvMzh9/ dVkrbMDhBk/ezwxTqfJkqDn//NOW6XyEbKPnbULJ7CiIm37kAHITl+D2hXRDTK4P566S 3PAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7PDLVJWJwvLrwfmKZw+n93ZjsWj5RspN5aikLjksBOg=; b=tXUMDU0R9dYmZJDUp29lZHmyAUElJ6Qz1St9bcannQ4k/zke+ezTXu6YSlNBDJflSN CkNHEuCcdL3YwcW03DaTjRtg3YMsQ2H3kMRrfETviPX1jWUwjHzH5oaDCm3DgOa53n6g 24/ve+++s/TlMlV7zFPOTEx5lrIbm/mOzZ9bU5Ib6xj5aXO7mjld2Xcd/78jS8ZMGMhp xpfA/qBn2O8M3epQ6I/zYUhziSNPN4tZbOELmEXw4fQVZPhPy7RODvChnUH0vmQ3q2Ck 0cTox0GGoayv33h/YCATFYuzkncIJIz0k6ltkS5ziQQ/0JIbhZSb8m+iGZDfif8fVwNv mFJw== X-Gm-Message-State: AOAM530cTcSyKA1Lv0iET/ozIUYtjLRnrSRA4LoXXc4I6xARt/A/jKVK 3N2mTaADfnqvb4mTG4Q4qHAVzxKIdFE3O3XKMA== X-Google-Smtp-Source: ABdhPJzHcyQ7uC+8uQEHfmb7v3sQ+5vH1qatz/VUn113xqC5g9Caw6Fx/1vg/VX3wj8/6VvIE3zXwdfu2gHFKVjsaQM= X-Received: by 2002:a05:600c:2049:: with SMTP id p9mr13178604wmg.147.1604261222176; Sun, 01 Nov 2020 12:07:02 -0800 (PST) In-Reply-To: <83v9eoeuud.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192461 Archived-At: --000000000000465cf705b3112c6e Content-Type: text/plain; charset="UTF-8" > 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 wrote: > > From: Paul Pogonyshev > > Date: Sun, 1 Nov 2020 19:56:09 +0100 > > Cc: Juri Linkov , 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. > --000000000000465cf705b3112c6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> It knows the binding of the character, and it knows o= ther things.

When it knows the bindings (99% of cases) i= t is called internally by
the command loop, so it doesn't eve= n go into Elisp domain here.
If something calls `read-event' = or similar on the Elisp level,
presumably they don't use keym= aps for whatever reasons and
process events specially. In this ca= se `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 d= ecide
> 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
<= div>would give Elisp access so that special users of `read-event' etc. = can
follow suit, but this would not oblige them to do anything. P= rograms
and modes that don't do anything special (either beca= use they are
old or do not care) will just behave as now, with no= effective changes.

Paul

On Sun, 1 Nov 2020 a= t 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.
--000000000000465cf705b3112c6e--