From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Sun, 10 Apr 2022 09:11:41 +0300 Message-ID: <83zgkt79ia.fsf@gnu.org> 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> <83fsmm8h0n.fsf@gnu.org> <87bkx9kb7d.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30572"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 08:14:40 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 1ndQqN-0007nX-FS for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 08:14:39 +0200 Original-Received: from localhost ([::1]:33720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndQqL-0001GI-L4 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 02:14:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndQnX-0007a1-Va for emacs-devel@gnu.org; Sun, 10 Apr 2022 02:11:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37290) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndQnX-0004si-MJ; Sun, 10 Apr 2022 02:11:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3z4IwnnpKU09wCc4xs/FUhDSEueGeFEYpSZ5okK0ljQ=; b=JhrXqg6pcOdC Z69omImWbNHg3J6kqKo5r+epTtCb0Qa1In7BOd/m4T/ENZj7W3CWXKa7Igo9U7i2vPrcCqffIFePv 8VgsEz03cIJNWkxASe9rXptsiWhO1j9WMxADfYXC+IYK2h9aGhKCMMaL3z1dWOHJhgUCzgZ4RXYrc tgXAs4YO2L9yuseaXjydYUE2xdcpLVEf6jwfMTtplXYLvNdvauOMJ03lpMTK0q2sac6lIw4ELc0/L 3jKAD8dutQKzASqYF6s6radFxzcjANt9XUHhaq0pEybxpzz6CRQdmbYd7+/ZFwM54tAr7DBlV5woL eMsSAEvIQK/of4sOsqWYGQ==; Original-Received: from [87.69.77.57] (port=4761 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndQnX-0003Ha-7J; Sun, 10 Apr 2022 02:11:43 -0400 In-Reply-To: <87bkx9kb7d.fsf@yahoo.com> (message from Po Lu on Sun, 10 Apr 2022 08:56:38 +0800) 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:288095 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sun, 10 Apr 2022 08:56:38 +0800 > > >> Unfortunately, our current representation is basically set in stone. > >> 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. > > > > We could keep the form, but add additional members to the list, no? > > That's simply too confusing, where different events have very different > indexes into the list to get the same property. Why "different indexes to get the same property"? The additional members should provide additional information, unavailable in the original elements. We already have such data structures in Emacs; see, for example, data structures returned by pos-visible-in-window-p and find-composition. The list returned by posn-at-point is another example: the 2nd member can be either display area or buffer position, and the 6th member always reports the position. So this is quite "normal" in Emacs, assuming that the data structure is designed to be convenient for the code that will use it.