Re: [Emacs-diffs] master b75fb81 1/4: Extend button.el to take callback data

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <address@hidden> 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