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

From: "Basil L. Contovounesios" <[email-masked]>
Date: Tue, 19 Feb 2019 15:26:59 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: "Basil L. Contovounesios" <[email-masked]>
>> Cc: <[email-masked]>,  <[email-masked]>
>> Date: Mon, 18 Feb 2019 20:51:12 +0000
>> 
>> 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".
>
> No, I'm trying to explain why button-type returns nil in the case of
> text-buttons.

I'm sorry if I've misunderstood something obvious, but button-type
should never return nil for any kind of button.el button, regardless of
whether it's a text or overlay button.

As stated in '(elisp) Button Types', "every button has a button type".
For example, the following should return 'button:

  (with-temp-buffer
    (let* ((tstart  (prog1 (point) (insert-text-button "text")))
           (ostart  (prog1 (point) (insert-button "overlay")))
           (tbutton (button-at tstart))
           (obutton (button-at ostart))
           (ttype   (button-type tbutton))
           (otype   (button-type obutton)))
      (cl-assert (and tbutton obutton ttype otype))
      (cl-assert (eq ttype otype))
      (cl-assert (eq ttype (button-type tstart)))
      (cl-assert (null (button-type ostart)))
      ttype))

[ By the way, would something like this be welcome as a start for
  test/lisp/button-tests.el? ]

The only cases (within reason) in which button-type may return nil are:

0. button-type is mistakenly given a buffer position POS instead of an
   overlay when the button at POS is an overlay (not text) button, as
   shown in the example above.  Using (button-at POS) avoids this
   problem.

1. button-type is given the value of a widget's (not button's) 'button
   overlay property.  This is not that far-fetched since both libraries
   rely on (get-char-property POS 'button), but I don't see why anyone
   would mix widgets and buttons in the same buffer and run the risk of
   such gotchas.  I believe this contributed in part to Robert's
   confusion.

Am I missing something?

-- 
Basil