From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master b75fb81 1/4: Extend button.el to take callback data Date: Fri, 02 Aug 2019 03:40:09 +0300 Message-ID: <878ssciemu.fsf@tcd.ie> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="143108"; 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: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 02 02:40:43 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 1htLcc-000b0h-4v for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2019 02:40:38 +0200 Original-Received: from localhost ([::1]:59944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htLcZ-0003N6-Eu for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2019 20:40:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50160) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htLcS-0003Lm-LC for emacs-devel@gnu.org; Thu, 01 Aug 2019 20:40:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htLcR-0000jO-BP for emacs-devel@gnu.org; Thu, 01 Aug 2019 20:40:28 -0400 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:43381) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1htLcP-0000c7-2S for emacs-devel@gnu.org; Thu, 01 Aug 2019 20:40:27 -0400 Original-Received: by mail-wr1-x42c.google.com with SMTP id p13so836122wru.10 for ; Thu, 01 Aug 2019 17:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=1ij6i1dqIcEFHE+3r6dhey/zyDKRzmTDExF5ebMsV0o=; b=r8XoOby+BuJ6nRFTfcoLNXD9BOUU3itP7Kg7sjsg22IL7T5OwSEsUov/kJ/5ts+bZp Pqkyc3OlLqbrfHS9+qg6K/LL4BHI1nSpj3+RSXZTNNq2nDAjMp0UftXMXwMIAY6PDlsn RggMxYQclwnmsos270LsEUYbu0bjxE2eLnUgv2On9LXPhk9WgmOnHbXh8DsFQMqBRvwp 6MgJPj4AtzZ/hWSdUAvB2QDkiYrseUjDYeyLroJfG3Puk9e1RryN7mx0DZmlkPW8Nefm nd1GMxugUWvhsrqtC9odfPd8eULkywVtzCrGyCGsC0h1ad+x0mTurqaTqUJwlnstV+sz 7kMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=1ij6i1dqIcEFHE+3r6dhey/zyDKRzmTDExF5ebMsV0o=; b=O1rBc9uyzZ6CYjtlbXRa0t64Y7irqQQlf9Fl4mNrRb7eBRzS238eJz1cx5hl1bGigP YePkGIVEBarP+GOAC/E24WcTehMBhtvCCMXhPTG6IQIhE3MGLINmui9Fllweo/WvRWYJ UFlDlUeeWdYjKMdh9Mpl85YIppaOXa+iPziYoHLQB8LFc0B0MrPA/aiycvIQggjoOccH hc8a2RBMdCxelMIpwLW8ZOUeXE54JYad/e+GxSDlM8xt8VKPYc1HVZJ/AAkjW5TNbYLV bbURgtOYhXi177nh3fTlHBHu/gu2fSo7PobRygIgYei47XGXSqin7meyKOVlZTMg4k+8 7amA== X-Gm-Message-State: APjAAAXs7fwWmAQGprFXUBxHNjlnPmtgyQtw2C6QJeqylJo2H0B0MqXj XnHaLySD0D8NVyV1BBlnlZ183w== X-Google-Smtp-Source: APXvYqzrYA4/uE1ymPD/COyQPFhZaUn9a5kuuBIz9jXoxLugLeqqrB/dYJTH1UyPEhOLjXH8gS+KpQ== X-Received: by 2002:a5d:498a:: with SMTP id r10mr54741256wrq.28.1564706421690; Thu, 01 Aug 2019 17:40:21 -0700 (PDT) Original-Received: from localhost (adsl-131.91.140.89.tellas.gr. [91.140.89.131]) by smtp.gmail.com with ESMTPSA id j33sm158869282wre.42.2019.08.01.17.40.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 01 Aug 2019 17:40:20 -0700 (PDT) In-Reply-To: <877e7wlv98.fsf@mouse.gnus.org> (Lars Ingebrigtsen's message of "Thu, 01 Aug 2019 18:12:51 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42c 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:239118 Archived-At: Lars Ingebrigtsen writes: > "Basil L. Contovounesios" writes: > >> I don't understand what you mean by "recreate the data" or "looking at >> the extent of the buttons". >> >> If an action function depends on some data associated with its button, >> then it is up to the creator or modifier of the button to tag it with >> that data. The action function then need only do a property lookup via >> button-get. > > Here's a typical usage: > > (make-text-button start (point) > 'face 'rcirc-url > 'follow-link t > 'rcirc-url url > 'action (lambda (button) > (browse-url (button-get button 'rcirc-url)))) > > with the "button knows the data" change, it's: > > (make-text-button start (point) > 'face 'rcirc-url > 'follow-link t > 'burron-data url > 'action #'browse-url) > > That looks like an interface improvement to me. I'm arguing that something like the following is a better interface improvement, because it doesn't require changing the interface: (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.) Providing such a convenience function in button.el (or one of its client libraries) affords the same brevity as the button-data approach, without changing the button API, making existing buttons more brittle, or sacrificing generality. 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? >> Alternatively, action functions can also be closures. > > They can be, in lexical packages. Sure; I only mentioned closures for completeness, not as a total solution. >> I don't mind the name 'button-data', and I wasn't worried about naming >> collisions. >> >> What I'm worried about is the existence of buttons in the wild, whose >> existing action functions will break if said buttons happen to be given >> a button-data property. This seems unnecessarily brittle and >> backward-incompatible, in exchange for what seems like an insufficiently >> useful convenience. Unless I'm missing something, that is. > > But you said you're not worried about naming collisions? How would > these buttons then "happen to be given" that property? 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? Thanks, -- Basil