Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Weiner <rsw@gnu.org>
>> Date: Sun, 17 Feb 2019 18:46:09 -0500
>> Cc: 34506@debbugs.gnu.org
>>
>> And what about (button-type (button-at (point))) returning
>> nil when button-at returns non-nil. Both of these functions
>> operate on push-buttons as the button.el code reflects, right?
>> If so, then that should be a bug. If not, then it could use
>> some explanation.
>
> button-type requires a button as an argument, whereas button-at is
> documented to return a marker for text-buttons. So you cannot safely
> invoke button-type if the button at point might be of the text-button
> type.
Buffer positions, markers, and overlays all qualify as "buttons", so
button-type works with both text- and overlay-buttons (but not widgets).
But as I think I noted in my first message, my recollection
is that button-type returned nil when given a marker value
returned from button-at. Since widgets use text-properties,
button-at on a widget can return a non-nil value, so to say that
widgets and buttons are unrelated ignores the programming API.
Maybe the solution is to add a more opaque programming abstraction
atop each type so that they don't expose their underlying implementations
and cause programming errors.
So I'm guessing what you meant is "you cannot safely invoke button-type
if the button at point might be a widget rather than a button".
Yes, again noting that widget documentation specifically mentions push-buttons
(push-button is the function used to activate buttons). This negates the idea
that the two constructs are wholly independent of each other.
Regards,
Bob