On Mon, Feb 18, 2019 at 3:51 PM Basil L. Contovounesios wrote: > Eli Zaretskii writes: > > >> From: Robert Weiner > >> 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