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:52:49 +0300 Message-ID: <83v8vh77lq.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> <83zgkt79ia.fsf@gnu.org> <87ilrhfoch.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10983"; 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:55: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 1ndRTX-0002f0-UK for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 08:55:07 +0200 Original-Received: from localhost ([::1]:35128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndRTW-0006BT-ET for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 02:55:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndRRN-0004ng-CJ for emacs-devel@gnu.org; Sun, 10 Apr 2022 02:52:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndRRN-0002Oa-0i; Sun, 10 Apr 2022 02:52:53 -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=r8x0vJ+TvUgx0Ws2q+Hx3cUhMjxRqC1UthPVl1CzVhc=; b=mebcul+DUbXp AkfbBzsS56hLgmAI/iaBn/7OV1RPV3z/sL+7FNOfs3kF6jeP1NMzj49+gvz6QfDal5VHBCYxtPl0s VVboYJZH1/EIOl0oCLUQ7xYcHvo+jwbFmjB1kVkUD61nUVO97v1MvzB7Uy+/AFYGQ8kOijmaMSV11 pilkg4v/RLUEvA78gHlDkWiOkg8vRfx0XyHyzqyEzWrxsaxcST7ylJuvjQYaTs4r21BGg6mjTgO5c zr95EMIW1+RlkOdx/l6z01p2o2Yvo09G0gSTDiEzkcRMEGlgrbHSq1vcedqLAqkO4Fqs7/tva0Itr fXIV3wweVkTZMxXpP7z7/g==; Original-Received: from [87.69.77.57] (port=3473 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 1ndRRL-0002TX-Fs; Sun, 10 Apr 2022 02:52:52 -0400 In-Reply-To: <87ilrhfoch.fsf@yahoo.com> (message from Po Lu on Sun, 10 Apr 2022 14:23:58 +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:288107 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sun, 10 Apr 2022 14:23:58 +0800 > > Eli Zaretskii writes: > > > 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. > > Because it doesn't make sense for this additional information to obscure > information that is already available. > > For example, we might extend `wheel-up' and `wheel-down' with an extra > DEVICE parameter, so that it might look something like this: > > (wheel-down POSITION CLICKS LINES PIXEL-DELTA DEVICE) > > But for touch end events, it would look like this: > > (touch-end POSITION DEVICE) > > And for pinch events, > > (pinch POSITION DX DY SCALE ANGLE DEVICE) > > To access the device would require the 6th, 3rd and 7th elements of each > type of event, which is very confusing. We have this in many places in Emacs already, so adding one more will not hurt too much. Dispatch on the first element of the list is easy and produces code that is quite readable and maintainable, IMO. Of course, if more elegant ways exist, I don't object to using them, quite the contrary. But if not, I see nothing especially wrong with doing what you call "very confusing", because we do it elsewhere.