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 10:20:06 -0400 Message-ID: References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <20220407133623.9C209C009A8@vcs2.savannah.gnu.org> <87ee28xyg2.fsf@yahoo.com> <87lewfqf1q.fsf@yahoo.com> <87zgkvosia.fsf@yahoo.com> <87pmlql6mj.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20639"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 16:21:56 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 1ndByM-00058D-Kw for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 16:21:54 +0200 Original-Received: from localhost ([::1]:42836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndByL-0004bf-BL for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 10:21:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndBxI-0003uh-FL for emacs-devel@gnu.org; Sat, 09 Apr 2022 10:20:48 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33036) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndBxF-0000qw-LX for emacs-devel@gnu.org; Sat, 09 Apr 2022 10:20:47 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C3C61001D2; Sat, 9 Apr 2022 10:20:44 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 62C7C100134; Sat, 9 Apr 2022 10:20:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649514042; bh=7W7RDvy+nFoq+Rs03SE1cl2YXLxZImp92FS1uf0xgnk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YaDn4rFsxjmw3/bGMcbqa+LtF2+tb3pjF5TXOyt/euIkKEBla2GC8hRUufFcN60Zr bPKN52GkmikROoe6EYW5wG8V2M5aPcDCI41WSNtAecylcDC4Y9GOAWB/3Io8y2TJN0 ymt5A4cUeeQuGStaqlT0hxPVTTxiF7wvNGn2gHnhbkPl7YscZBXUzSRx7hqRFphPfC i2eii72oprFEVjHKlPp/mQIxvLShLHByBqsszn/KGE8qVEJmbYZ5h/VPn54JPwNOPD xcCeJJQEMtumqEm/pRSnJx+4tKT/ikSF7Z+QTskvwtI/GRYSvYWzYQDvj+HylUOvQJ yL4W9VnXrMH7g== Original-Received: from alfajor (modemcable034.207-20-96.mc.videotron.ca [96.20.207.34]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 377351204D7; Sat, 9 Apr 2022 10:20:42 -0400 (EDT) In-Reply-To: <87pmlql6mj.fsf@yahoo.com> (Po Lu's message of "Sat, 09 Apr 2022 21:37:56 +0800") 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:288026 Archived-At: >> But I agree that the current representation of events is problematic. >> We should make it more regular and self-descriptive, either based on an >> alist as above or have every event come with some kind of "class" which >> then describes the name&position of every accompanying data. > Unfortunately, our current representation is basically set in stone. To some extent, yes, but we can try and design the new representation to be compatible with the old one. E.g. the "class" could be obtained via: (defun event-class (e) (if (consp e) (get (event-basic-type e) 'event-class) character-event-class)) > There is too much Lisp out there that relies on the current form of Lisp > events, and simply finding all that code will be a serious chore. Yup, that's why we have to introduce the new API in a way that's backward compatible. > Maybe we could introduce a new representation of event in addition to > the current form, with a its own interactive form and read-event, that > represents events as some better data structure? Here, I'd side with Eli and say that the resulting code churn wojuld be more trouble than it's worth. [ Most of that work has already been done in the context of XEmacs, but I doubt we'd be able to make use of it, sadly. ] Stefan