From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Sat, 09 Apr 2022 12:33:00 -0400 Message-ID: References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <20220407133623.9C209C009A8@vcs2.savannah.gnu.org> <87ee28xyg2.fsf@yahoo.com> <83ee28az95.fsf@gnu.org> <87fsmow1hz.fsf@yahoo.com> <83a6cway59.fsf@gnu.org> <87tub4uivu.fsf@yahoo.com> <83y20fakwn.fsf@gnu.org> <87o81bu7zj.fsf@yahoo.com> <83v8vjai4s.fsf@gnu.org> <87bkxbsqfl.fsf@yahoo.com> <835yniah0u.fsf@gnu.org> <8735impqw4.fsf@yahoo.com> <83v8vi8uyu.fsf@gnu.org> <871qy6o9p3.fsf@yahoo.com> <83o81a8qnd.fsf@gnu.org> <87zgkulbuu.fsf@yahoo.com> <83ilri8iag.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1129"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Po Lu , Richard Stallman , Lars Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 18:34:08 2022 Return-path: Envelope-to: ged-emacs-devel@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 1ndE2J-000AcL-HS for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 18:34:07 +0200 Original-Received: from localhost ([::1]:52964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndE2I-0005Wd-GA for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 12:34:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndE1d-0004ru-3s for emacs-devel@gnu.org; Sat, 09 Apr 2022 12:33:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38321) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndE1a-0002lS-5u; Sat, 09 Apr 2022 12:33:23 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6F49D440648; Sat, 9 Apr 2022 12:33:19 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CC240440635; Sat, 9 Apr 2022 12:33:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649521997; bh=efHnVoXNCtYeyaSu9dlfnulNKo+ZfwnDKqVVmnz0JC0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hT8lUfymIo3LgFJGbTue7n+1wcl4y4JQ4fPrMHqGL0o99d1Dj/0O89TBUvqACj3IO 8Gz+EJCWBylWDApGTHIHrpaAb/wom9dI9ppMWAMcKdGUw33Ak0MxBLV+mFbIEqnIXx GDkQHeOqsIunZOwLbhApibiJFJLtMRBAcpdatBmS3TZAhuU7vKMgFSp6At1ZQtusJR IicEZGJEVymCV0o12YIzN/DIqRGDH8MpwVmNWNeaRvxydh7xWNf6lDm/H6cZftvkm2 lg5nM3raOc/7y7PrqTOHeFIuIooerNrzGYd+8MXoB6yHSHRLXOI0a7FWSghPVUnqlO WNMUupbEE9qjA== Original-Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68E6D1202D5; Sat, 9 Apr 2022 12:33:17 -0400 (EDT) In-Reply-To: <83ilri8iag.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Apr 2022 17:04:23 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288035 Archived-At: > If the events are to be interpreted as usual in some situations and > differently in others, we could have a special mode or variable to > change the produced events only when we want that to be. I'd prefer we don't do that. This is the kind of thing we do for `keyboard-coding-system` (the (sequence of) events we generate depends on that variable) and it causes real problems for all those places in the code that want to peek at the next event without consuming it (starting with `sit-for`). > Alternatively, we could always produce special kinds of events, and > have them mapped to the same commands as the "normal" events. For > example, touchpad-button-1 could be mapped to the same command as > mouse-1 in most cases, but when we want to treat those touchpad events > specially, we could rebind them to other commands. This behaves better, indeed. The downside is that we currently don't have a good way to define remapping like `touchpad-button-1` to `mouse-1` (the mechanism we have works for that exact event but you then need to add N other mappings for the cases where it's combined with control, meta, meta+control, hyper+control, shift+control+double, ...). >> The individual command will have to know about the device to treat it >> correctly, just as elsewhere: web browsers, programs using GTK, Qt, etc. Elsewhere tells us that the behavior depends on the device, but not that the choice is made within their equivalent of "individual commands" nor that this place would be the better choice. I don't know where's the better place in general but if it can be made via keymaps it might be preferable since we usually don't like commands to behave differently for different events, we prefer instead to have the keymaps decide which command to use for which event and then have the command be oblivious to the event. [ There are some notable exceptions to this general design, admittedly. E.g. `self-insert-command` looks at the event to know which char to insert, or the commands which obey `use-dialog-box` of those that obey `shift-select-mode`. ] > Does this really sound clean and maintainable? Am I really the only > one who's worried by that kind of design? Stefan, Lars, Richard? I agree that we'll usually want to hide those issues from commands. I don't think the current code which exposes the device name to ELisp is wrong, OTOH (after all, I like to keep the C code to a minimum). But it's just not sufficient in the sense that we want to add to it some abstraction layer so individual commands don't need to know about the various possible input devices. Stefan