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

Previous Next

Full log

Message #38 received at 34506 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34506 <at> debbugs.gnu.org, rswgnu <at> gmail.com
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Tue, 19 Feb 2019 15:26:59 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: <rswgnu <at> gmail.com>,  <34506 <at> debbugs.gnu.org>
>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.