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

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Mon, Feb 18, 2019 at 3:51 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 3817 bytes --]