From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master b75fb81 1/4: Extend button.el to take callback data Date: Fri, 02 Aug 2019 20:46:56 +0200 Message-ID: <87mugro15r.fsf@mouse.gnus.org> References: <20190730132507.32385.70681@vcs0.savannah.gnu.org> <20190730132509.77D2820C0A@vcs0.savannah.gnu.org> <87lfwd2ihn.fsf@tcd.ie> <87pnlpm5x9.fsf@mouse.gnus.org> <87ef24vrpz.fsf@tcd.ie> <877e7wlv98.fsf@mouse.gnus.org> <878ssciemu.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="234942"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 02 20:49:21 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htccC-000yxd-TL for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2019 20:49:21 +0200 Original-Received: from localhost ([::1]:36970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htccB-0001qE-O4 for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2019 14:49:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38818) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htca1-0001o5-Bz for emacs-devel@gnu.org; Fri, 02 Aug 2019 14:47:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htca0-0005n2-64 for emacs-devel@gnu.org; Fri, 02 Aug 2019 14:47:05 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:56710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1htcZz-0005l0-V0 for emacs-devel@gnu.org; Fri, 02 Aug 2019 14:47:04 -0400 Original-Received: from 77.18.62.220.tmi.telenormobil.no ([77.18.62.220] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htcZt-0004x7-Ca; Fri, 02 Aug 2019 20:46:59 +0200 In-Reply-To: <878ssciemu.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 02 Aug 2019 03:40:09 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239145 Archived-At: "Basil L. Contovounesios" writes: > (defun button-callback-action (button) > "Call BUTTON's `button-callback' property." > (apply #'funcall (button-get button 'button-callback))) > > (define-button-type 'rcirc-url > 'face 'rcirc-url > 'follow-link t > 'action #'button-callback-action) > > (make-text-button start (point) > 'type 'rcirc-url > 'button-callback (list #'browse-url url)) > > (Using define-button-type is optional, but encouraged.) Button is such a nice and light-weight library (especially compared to widget). Having to write these wrapper functions to do these trivial transforms is the one bad thing in the API. > Button action functions have until now expected a button as an argument, > but now they may or may not be given a button, and this is determined by > the presence or not of a button property. Why introduce this brittle > backward incompatibility? I don't see how it's brittle, and it's not backwards incompatible. If you add a 'button-data 'foo to your buttons, then you presumably want your action to get the data. Otherwise, why would you do it? > Oh, we seem to be interpreting "naming collision" slightly differently. > > I took it to mean that a client of the button library has used a > property name for one purpose, which is used for another purpose > elsewhere. > > But what is happening here is that existing code is written with the > assumption that button action functions receive a button as argument. > This assumption now breaks down on buttons with a non-nil button-data > property. Why make this unnecessary and backward-incompatible change? I still don't understand what you mean here. If somebody writes a new button that has 'button-data, how does that affect the existing button? If you write a new button, and say 'button-data, then the 'action you've written takes that data as the argument, not the button. There's nobody randomly adding 'button-data to random existing code, surely? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no