Subject: bug#34506: 27.0.50: push-button bug with basic text-property button

From: Robert Weiner <[email-masked]>
Date: Mon, 18 Feb 2019 17:54:06 -0500

On Mon, Feb 18, 2019 at 3:51 PM Basil L. Contovounesios <[email-masked]>
wrote:

> Eli Zaretskii <[email-masked]> writes:
>
> >> From: Robert Weiner <[email-masked]>
> >> Date: Sun, 17 Feb 2019 18:46:09 -0500
> >> Cc: [email-masked]
> >>
> >> 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