From: Lars Ingebrigtsen <larsi@gnus.org>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master b75fb81 1/4: Extend button.el to take callback data
Date: Thu, 01 Aug 2019 14:22:26 +0200 [thread overview]
Message-ID: <87pnlpm5x9.fsf@mouse.gnus.org> (raw)
In-Reply-To: <87lfwd2ihn.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 01 Aug 2019 15:11:16 +0300")
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Can you please explain the rationale behind this? I'm not sure it's a
> good idea:
>
> 1. Arbitrary data can already be associated with buttons and retrieved
> in their action functions using button-get, button-put, and on button
> creation with make{,-text}-button et al.
>
> 2. AIUI this is a potentially backward-incompatible change, as existing
> action functions, which expect to receive a button, may now receive
> the value of the button-data property instead.
>
> So at first glance I'm not convinced the minor convenience of not having
> to manually (button-get button 'button-data) or similar in the action
> function is worth messing with the pre-existent and cleaner API. Am I
> missing something?
Button callback functions currently often recreate the data they need by
looking at the extent of the buttons. This is an awkward interface,
because when creating the buttons, the functions have already determined
what the data should be. So it'd a way to de-duplicate code. If you
look at the functions in Gnus that use this now, you can see how the
callback functions can be completely oblivious to having be called
through a button.el callback, which is how it should be.
As for the name collision issue -- that's why I didn't call it just
`data' or the like. button.el already uses property names like
`action', which is unfortunate, as that really is prone to naming
collisions, but I grepped through the tree, and there are no in-tree
usages of the `button-data' property.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2019-08-01 12:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190730132507.32385.70681@vcs0.savannah.gnu.org>
[not found] ` <20190730132509.77D2820C0A@vcs0.savannah.gnu.org>
2019-08-01 12:11 ` [Emacs-diffs] master b75fb81 1/4: Extend button.el to take callback data Basil L. Contovounesios
2019-08-01 12:22 ` Lars Ingebrigtsen [this message]
2019-08-01 15:19 ` Basil L. Contovounesios
2019-08-01 16:12 ` Lars Ingebrigtsen
2019-08-01 20:44 ` Stefan Monnier
2019-08-02 18:41 ` Lars Ingebrigtsen
2019-08-02 0:40 ` Basil L. Contovounesios
2019-08-02 18:46 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pnlpm5x9.fsf@mouse.gnus.org \
--to=larsi@gnus.org \
--cc=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.