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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34506 in the body.
You can then email your comments to 34506 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Bob Weiner <rsw <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50: push-button bug with basic text-property button
Date: Sat, 16 Feb 2019 17:08:47 -0500

From the Elisp manual (https://www.gnu.org/software/emacs/manual/html_node/elisp/Manipulating-Buttons.html), we have these accurate explanations:

  — Function: button-at pos
  Return the button at position pos in the current buffer, or nil. If the button at pos is a text property button, the return value is a marker pointing to pos.

  — Function: button-activate button &optional use-mouse-action
  Call button's action property (i.e., invoke the function that is the value of that property, passing it the single argument button). If use-mouse-action is non-nil, try to invoke the button's mouse-action property instead of action; if the button has no mouse-action property, use action as normal.

-----

With point on a "Choose" button in a customize-group buffer, point is on
a text-property button and (button-at (point)) returns a marker object
rather than a button whose action is a marker object.  Thus, if one
calls (push-button) at that location, it sends this marker object as the
button argument to 'button-activate' which then triggers an error when
it tries to funcall the button's action which is nil in this case.
Shouldn't there be additional logic that checks if the button itself is
a marker and then uses the button as the action in that case?

Related to this:  (button-type (button-at (point))) returns nil which seems
to contradict the fact that button-at returns non-nil.

Am I missing things here or does button-activate need additional code?

Thanks,

Bob


-------



In GNU Emacs 27.0.50 (build 13, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G1036))
 of 2017-12-17 built on bka-iMac.local
Repository revision: 36375d35aa06e84865cce678559ddfa8f79a9775
Windowing system distributor 'Apple', version 10.3.1561
Recent messages:
[Sat 04:46:35 PM] 
[Sat 04:46:35 PM] 
[Sat 04:46:35 PM] Result: nil
[Sat 04:46:37 PM] 
[Sat 04:46:37 PM] 
[Sat 04:46:37 PM] Result: nil
[Sat 04:46:38 PM] 
[Sat 04:46:38 PM] nil
[Sat 04:47:16 PM] 
Back to top level

Configured using:
 'configure --with-ns --with-imagemagick --without-pop --with-mailutils
 CC=clang 'CFLAGS=-O3 -g''

Configured features:
JPEG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Custom

Minor modes in effect:
  recentf-mode: t
  treemacs-follow-mode: t
  treemacs-filewatch-mode: t
  treemacs-git-mode: deferred
  treemacs-fringe-indicator-mode: t
  async-bytecomp-package-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  winner-mode: t
  which-key-mode: t
  which-function-mode: t
  persistent-scratch-autosave-mode: t
  global-edit-server-edit-mode: t
  delete-selection-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  column-number-indicator-zero-based: t
  dynamic-completion-mode: t
  eros-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  global-company-mode: t
  company-mode: t
  ace-window-display-mode: t
  major-mode-icons-mode: t
  minibuffer-depth-indicate-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bob Weiner <rsw <at> gnu.org>
Cc: 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Sun, 17 Feb 2019 17:24:27 +0200

> From: Bob Weiner <rsw <at> gnu.org>
> Date: Sat, 16 Feb 2019 17:08:47 -0500
> 
> With point on a "Choose" button in a customize-group buffer, point is on
> a text-property button and (button-at (point)) returns a marker object
> rather than a button whose action is a marker object.  Thus, if one
> calls (push-button) at that location, it sends this marker object as the
> button argument to 'button-activate' which then triggers an error when
> it tries to funcall the button's action which is nil in this case.
> Shouldn't there be additional logic that checks if the button itself is
> a marker and then uses the button as the action in that case?
> 
> Related to this:  (button-type (button-at (point))) returns nil which seems
> to contradict the fact that button-at returns non-nil.
> 
> Am I missing things here or does button-activate need additional code?

button-activate and push-button already include that additional code,
but you are trying to invoke them on a kind of "button" that they
don't know how to handle.  The problem is that "button" is overloaded
here: buttons created by Customize are not of the kind supported by
functions from button.el, you need to invoke functions described in
widget.info instead.  The "text-property buttons" mentioned in the
documentation of button-at etc. are those created by make-text-button
and insert-text-button, not those created by Customize.

The ELisp manual hints on this at the beginning the parent node,
"Buttons".  Maybe that's not clear enough; patches to make that more
clear are welcome.  Other than that, I don't see a bug here.

Thanks.

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

From: Robert Weiner <rsw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Sun, 17 Feb 2019 18:46:09 -0500

[Message part 1 (text/plain, inline)]

On Sun, Feb 17, 2019 at 10:24 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Bob Weiner <rsw <at> gnu.org>
> > Date: Sat, 16 Feb 2019 17:08:47 -0500
> >
> > With point on a "Choose" button in a customize-group buffer, point is on
> > a text-property button and (button-at (point)) returns a marker object
> > rather than a button whose action is a marker object.  Thus, if one
> > calls (push-button) at that location, it sends this marker object as the
> > button argument to 'button-activate' which then triggers an error when
> > it tries to funcall the button's action which is nil in this case.
> > Shouldn't there be additional logic that checks if the button itself is
> > a marker and then uses the button as the action in that case?
> >
> > Related to this:  (button-type (button-at (point))) returns nil which
> seems
> > to contradict the fact that button-at returns non-nil.
> >
> > Am I missing things here or does button-activate need additional code?
>
> button-activate and push-button already include that additional code,
> but you are trying to invoke them on a kind of "button" that they
> don't know how to handle.  The problem is that "button" is overloaded
> here: buttons created by Customize are not of the kind supported by
> functions from button.el, you need to invoke functions described in
> widget.info instead.  The "text-property buttons" mentioned in the
> documentation of button-at etc. are those created by make-text-button
> and insert-text-button, not those created by Customize.
>

I really don't fully understand what you are saying here.
There is a section in widget.info which describes use of the (push-button)
function which is defined in button.el, so although I
understand you are saying there are two different types
of buttons, it seems like they are connected.  Maybe
the custom widgets use text-property buttons.

If you could, for each of the two types of buttons,
just show code that finds the button at point and then
activates it, so I can see the difference clearly.  That
would be most helpful.

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.

Thanks,

Bob

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rswgnu <at> gmail.com
Cc: 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Mon, 18 Feb 2019 17:47:32 +0200

> From: Robert Weiner <rsw <at> gnu.org>
> Date: Sun, 17 Feb 2019 18:46:09 -0500
> Cc: 34506 <at> debbugs.gnu.org
> 
>  button-activate and push-button already include that additional code,
>  but you are trying to invoke them on a kind of "button" that they
>  don't know how to handle.  The problem is that "button" is overloaded
>  here: buttons created by Customize are not of the kind supported by
>  functions from button.el, you need to invoke functions described in
>  widget.info instead.  The "text-property buttons" mentioned in the
>  documentation of button-at etc. are those created by make-text-button
>  and insert-text-button, not those created by Customize.
> 
> I really don't fully understand what you are saying here.

I'm saying that a "button" created by Customize is radically different
from "buttons" that button.el functions can handle.  They are
different objects, and it's unfortunate that both kinds are named the
same.

> There is a section in widget.info which describes use of the (push-button)
> function which is defined in button.el

No, push-button described in widget.info is a type of widget, not a
function.  Again, the same name used for two very different things.

> Maybe the custom widgets use text-property buttons.

Custom widget button do indeed use text properties, but those
properties are entirely different from the properties used by
text-buttons created by button.el.  You can see that yourself by using
the describe-text-properties command with point on each type of
button.

> If you could, for each of the two types of buttons,
> just show code that finds the button at point and then
> activates it, so I can see the difference clearly.  That
> would be most helpful.

If you type "C-h c RET" on a button in a Customize buffer, you will
see that RET invokes Custom-newline there -- this is the way to "push"
the button widgets that Custom uses.  By contrast, if you do the same
on a button created by button.el, like a hyperlink in the *Help*
buffer, you will see that RET invokes the command push-button there, a
different command.  These are the two ways of pushing these two
different kinds of buttons.

> 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.  IOW, the text-button is not an object, it is a place in the
buffer where the button starts.

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

From: Robert Weiner <rsw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Mon, 18 Feb 2019 11:56:49 -0500

[Message part 1 (text/plain, inline)]

Thanks Eli, that is much clearer.  I can work with that explanation.

Your last paragraph indicates that the button API by itself could use some
improvement.
How does one obtain a button to send to button-type if not button-at?

Also, a confusing part of the widget documentation is this:

-------

5.4 The ‘push-button’ Widget
============================

Syntax:

     TYPE ::= (push-button [KEYWORD ARGUMENT]...  [ VALUE ])

-------

The above syntax description of course looks like a lisp-function call of
push-button.
At the very least, changing this thing's name to widget-button would
prevent such
confusion.

-- Bob

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rswgnu <at> gmail.com
Cc: 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Mon, 18 Feb 2019 19:36:52 +0200

> From: Robert Weiner <rsw <at> gnu.org>
> Date: Mon, 18 Feb 2019 11:56:49 -0500
> Cc: 34506 <at> debbugs.gnu.org
> 
> Your last paragraph indicates that the button API by itself could use some improvement.

Possibly.

> How does one obtain a button to send to button-type if not button-at?

Looks like you need to use text-properties-at, and then look at the
result: the type is stored in the 'category' property there.

Message #23 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: Mon, 18 Feb 2019 20:51:12 +0000

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

>> From: Robert Weiner <rsw <at> gnu.org>
>> Date: Sun, 17 Feb 2019 18:46:09 -0500
>> Cc: 34506 <at> 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).

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".

-- 
Basil

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Robert Weiner <rsw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rswgnu <at> gmail.com, 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Mon, 18 Feb 2019 20:52:27 +0000

Robert Weiner <rsw <at> gnu.org> writes:

> Thanks Eli, that is much clearer.  I can work with that explanation.
>
> Your last paragraph indicates that the button API by itself could use
> some improvement.  How does one obtain a button to send to button-type
> if not button-at?

You can use button-at if you want to be agnostic of the button (not
widget) type.  If you're only dealing with text (not overlay) buttons,
you can avoid creating markers by passing a buffer position like (point)
directly to button-type.

If you are dealing with widgets, on the other hand, you should use
widget-at and widget-type in place of button-at and button-type,
respectively.  The widget and button APIs are mutually incompatible.

-- 
Basil

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

From: Robert Weiner <rsw <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Mon, 18 Feb 2019 17:54:06 -0500

[Message part 1 (text/plain, inline)]

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

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Robert Weiner <rsw <at> gnu.org>
> >> Date: Sun, 17 Feb 2019 18:46:09 -0500
> >> Cc: 34506 <at> 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

[Message part 2 (text/html, inline)]

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

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

Robert Weiner <rsw <at> gnu.org> writes:

> On Mon, Feb 18, 2019 at 3:51 PM Basil L. Contovounesios <contovob <at> tcd.ie> wrote:
>
>  Eli Zaretskii <eliz <at> gnu.org> writes:
>
>  >> From: Robert Weiner <rsw <at> gnu.org>
>  >> Date: Sun, 17 Feb 2019 18:46:09 -0500
>  >> Cc: 34506 <at> 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.

I think what's confusing you is that button-at returns a marker even
when there is no button at point.  If either of the following two
expressions evaluates to nil, then there is no button at point:

  (button-type (button-at (point)))
  (button-type (point))

If there is something that *looks* like a button at point, yet these
expressions evaluate to nil, then you're probably looking at a widget
instead.

>  Since widgets use text-properties,

AFAICT Customize widgets use overlays, not text properties.  I concluded
this by comparing the results of (text-properties-at (point)) and
(overlays-at (point)) with point at a Customize button.

> button-at on a widget can return a non-nil value, so to say that
> widgets and buttons are unrelated ignores the programming API.

Again, that button-at returns a marker for a widget is a coincidence,
not part of either library's API.  Last time I read/skimmed the relevant
manuals I was not given the impression that these libraries were
related, but suggestions for clarification of their text is always
welcome.

> 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.

Can you please elaborate?  I don't see how either library's
implementation is exposed beyond what is documented in its respective
manual.

>  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).

push-button is indeed a button.el function used to activate buttons, but
this has nothing to do with the push-button widget type, which is
documented under '(widget) Introduction' and '(widget) push-button'.

> This negates the idea that the two constructs are wholly independent
> of each other.

I hope I have managed to convince you otherwise.

-- 
Basil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
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 05:29:48 +0200

> 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.

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

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

From: Robert Weiner <rswgnu <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34506 <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Wed, 20 Feb 2019 00:22:44 -0500

> On Feb 19, 2019, at 10:26 AM, Basil L. Contovounesios <contovob <at> tcd.ie> wrote:
> 
> 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.

If buttons and widgets are wholly incompatible and separate then button-at should return nil when on a widget even if both buttons and widgets use the same underlying mechanism.  This is what abstractions are for.  The implementation should be hidden.

The abstraction I really want is if there is a clickable item under point, activate it in the most appropriate way, e.g. if selected with a mouse event, use it’s mouse action, etc.  Maybe an activate-at function that handles different types of objects with a priority order if there are multiple matches. 

Bob

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

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

[Message part 1 (text/plain, inline)]

Robert Weiner <rswgnu <at> gmail.com> writes:

>> On Feb 19, 2019, at 10:26 AM, Basil L. Contovounesios <contovob <at> tcd.ie> wrote:
>> 
>> 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.
>
> If buttons and widgets are wholly incompatible and separate then button-at
> should return nil when on a widget even if both buttons and widgets use the same
> underlying mechanism.

How's the following?

[button.diff (text/x-diff, inline)]

diff --git a/lisp/button.el b/lisp/button.el
index c46f3d9a52..921e84dfa6 100644
--- a/lisp/button.el
+++ b/lisp/button.el
@@ -382,10 +382,12 @@ button-at
 If the button at POS is a text property button, the return value
 is a marker pointing to POS."
   (let ((button (get-char-property pos 'button)))
-    (if (or (overlayp button) (null button))
-	button
-      ;; Must be a text-property button; return a marker pointing to it.
-      (copy-marker pos t))))
+    (and button (get-char-property pos 'category)
+         (if (overlayp button)
+             button
+           ;; Must be a text-property button;
+           ;; return a marker pointing to it.
+           (copy-marker pos t)))))
 
 (defun next-button (pos &optional count-current)
   "Return the next button after position POS in the current buffer.
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 52c0b5b74d..b9f98cdc4c 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -1163,8 +1163,9 @@ widget-field-list
 
 (defun widget-at (&optional pos)
   "The button or field at POS (default, point)."
-  (or (get-char-property (or pos (point)) 'button)
-      (widget-field-at pos)))
+  (let ((widget (or (get-char-property (or pos (point)) 'button)
+                    (widget-field-at pos))))
+    (and (widgetp widget) widget)))
 
 ;;;###autoload
 (defun widget-setup ()

[Message part 3 (text/plain, inline)]

-- 
Basil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
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: Sat, 02 Mar 2019 14:34:24 +0200

> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34506 <at> debbugs.gnu.org
> Date: Mon, 25 Feb 2019 02:40:26 +0000
> 
> > If buttons and widgets are wholly incompatible and separate then button-at
> > should return nil when on a widget even if both buttons and widgets use the same
> > underlying mechanism.
> 
> How's the following?

LGTM, but can we please have a simple test for this, so that this
never again regresses?

Thanks.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rswgnu <at> gmail.com, 34506-done <at> debbugs.gnu.org
Subject: Re: bug#34506: 27.0.50: push-button bug with basic text-property
 button
Date: Sun, 07 Apr 2019 04:14:09 +0100

[Message part 1 (text/plain, inline)]

tags 34506 fixed
close 34506
quit

[0001-Distinguish-buttons-from-widgets-bug-34506.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

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

>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 34506 <at> debbugs.gnu.org
>> Date: Mon, 25 Feb 2019 02:40:26 +0000
>> 
>> > If buttons and widgets are wholly incompatible and separate then button-at
>> > should return nil when on a widget even if both buttons and widgets use the same
>> > underlying mechanism.
>> 
>> How's the following?
>
> LGTM, but can we please have a simple test for this, so that this
> never again regresses?

Of course.  I've pushed the attached patch to master, and am thus
closing this bug report.  Let me know if I missed anything.

Thanks,

-- 
Basil

Previous Next

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