[drew.adams@oracle.com: mouse-1-click-follows-link doesn't govern behavior in Customize]

[drew.adams@oracle.com: mouse-1-click-follows-link doesn't govern behavior in Customize]

[Richard Stallman]

Would someone please DTRT, then ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Sat, 28 Oct 2006 19:40:08 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: mouse-1-click-follows-link doesn't govern behavior in Customize
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

emacs -Q
M-x set-variable mouse-1-click-follows-link RET nil RET
M-x customize-option read-quoted-char-radix RET

Click mouse-1 on the first line, text `read-quoted-char'. This opens
the *Help* buffer with a description of `read-quoted-char'.

With `mouse-1-click-follows-link', I would not expect mouse-1 do do
that; I would expect only mouse-2 to do that. If someone sets
`mouse-1-click-follows-link' to nil, it is likely that that user does
not want mouse-1 to do more than set point.


In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
 of 2006-07-19 on BOS-CTHEWLAP2
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-msvc (12.00)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Custom

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-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
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t




_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn't govern behavior in Customize]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Would someone please DTRT, then ack?

The buttons in the customize buffer are not links; they are buttons.

> From: "Drew Adams" <drew.adams@oracle.com>
> Subject: mouse-1-click-follows-link doesn't govern behavior in Customize
> To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
>
> emacs -Q
> M-x set-variable mouse-1-click-follows-link RET nil RET
> M-x customize-option read-quoted-char-radix RET
>
> Click mouse-1 on the first line, text `read-quoted-char'. This opens
> the *Help* buffer with a description of `read-quoted-char'.
>
> With `mouse-1-click-follows-link', I would not expect mouse-1 do do
> that; I would expect only mouse-2 to do that. If someone sets
> `mouse-1-click-follows-link' to nil, it is likely that that user does
> not want mouse-1 to do more than set point.
>
>
> In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
>  of 2006-07-19 on BOS-CTHEWLAP2
> X server distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-msvc (12.00)'
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   locale-coding-system: cp1252
>   default-enable-multibyte-characters: t
>
> Major mode: Custom
>
> Minor modes in effect:
>   encoded-kbd-mode: t
>   tooltip-mode: t
>   tool-bar-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
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>
>
>
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Drew Adams]

    > Would someone please DTRT, then ack?
    
    The buttons in the customize buffer are not links; they are buttons.

Please read the bug description.
This is linked text in the doc string; it is not a button.
    
    > emacs -Q
    > M-x set-variable mouse-1-click-follows-link RET nil RET
    > M-x customize-option read-quoted-char-radix RET
    >
    > Click mouse-1 on the first line, text `read-quoted-char'. This opens
    > the *Help* buffer with a description of `read-quoted-char'.

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>     > Would someone please DTRT, then ack?
>     
>     The buttons in the customize buffer are not links; they are buttons.
>
> Please read the bug description.
> This is linked text in the doc string; it is not a button.

OTOH, it is not straightforward to implement the
mouse-1-click-follows-link behavior for widgets, including link
widgets: in particular, the part where holding the button down for a
certain time causes point to move.  In any case, I don't think we
should think about this until after the release.

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Richard Stallman]

    OTOH, it is not straightforward to implement the
    mouse-1-click-follows-link behavior for widgets, including link
    widgets: in particular, the part where holding the button down for a
    certain time causes point to move.

C-h v read-quoted-char-radix RET generates a buffer with a link.
It obeys mouse-1-click-follows-link.

M-x customize-option RET read-quoted-char-radix RET creates a buffer
with a widget that looks just the same.  But it doesn't act the same.
This is very bad UI design.

Could we change cus-edit.el to make a link instead of a widget?
But changing widget-documentation-link-add, say?

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     OTOH, it is not straightforward to implement the
>     mouse-1-click-follows-link behavior for widgets, including link
>     widgets: in particular, the part where holding the button down for a
>     certain time causes point to move.
>
> C-h v read-quoted-char-radix RET generates a buffer with a link.
> It obeys mouse-1-click-follows-link.
>
> M-x customize-option RET read-quoted-char-radix RET creates a buffer
> with a widget that looks just the same.  But it doesn't act the same.
> This is very bad UI design.
>
> Could we change cus-edit.el to make a link instead of a widget?
> But changing widget-documentation-link-add, say?

At the Lisp level, the custom-group-link widgets behave rather
differently from ordinary links used in, e.g., the *Help* buffer.
There's a lot amount of code in cus-edit.el that specifies an :action
for the custom-group-link widget when the widget is defined.  The
minimum required change is to (i) make these callers specify some
other widget property, say :link-action; (ii) somehow modify the
custom-group-link so that it is inserted along with text properties
that specify a mouse-2 local binding plus a `follow-link' property,
which automagically calls the :link-action of the widget.  It's a
pretty big project.

Recall that the link widgets were changed to look like links during
the Emacs 22 release process; previously they looked like buttons.
The change was made because they are conceptually links rather than
buttons, and people don't expect links to look like buttons.

I think the amount of inconsistency involved is negligible enough that
we can postphone it for after the release.

One compromise is to change the :pressed-face widget property of
custom-group-link widgets.  That way, they will change color when the
user holds down the mouse button, which is a visual cue that they
behave differently from other Emacs links.

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Richard Stallman]

    > Could we change cus-edit.el to make a link instead of a widget?
    > But changing widget-documentation-link-add, say?

    At the Lisp level, the custom-group-link widgets behave rather
    differently from ordinary links used in, e.g., the *Help* buffer.

I believe you, but aren't we talking about two different questions?
You're talking about how link widgets look and operate, and thus
addressing the possibility of changing how they look or how they
operate.

I am talking about the possibility of replacing the link widgets
with ordinary links.

Can't this be done with a localized change in
widget-documentation-link-add?

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > Could we change cus-edit.el to make a link instead of a widget?
>     > But changing widget-documentation-link-add, say?
>
>     At the Lisp level, the custom-group-link widgets behave rather
>     differently from ordinary links used in, e.g., the *Help* buffer.
>
> I believe you, but aren't we talking about two different questions?
> You're talking about how link widgets look and operate, and thus
> addressing the possibility of changing how they look or how they
> operate.
>
> I am talking about the possibility of replacing the link widgets
> with ordinary links.
>
> Can't this be done with a localized change in
> widget-documentation-link-add?

No, because that would not change the other *-link widgets (custom
group links, info links, etc) that are also present.  These are
generally specified at run-time using an :action argument, and there
is no single localized change that can be used to implement the
follow-link behavior fdor them.  Changing
widget-documentation-link-add would mean that documentation string
link widgets would behave differently from other link widgets in the
same Customize buffer!

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Richard Stallman]

    No, because that would not change the other *-link widgets (custom
    group links, info links, etc) that are also present.

But how hard would it be to make actual links for all those purposes,
instead of those widgets?

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     No, because that would not change the other *-link widgets (custom
>     group links, info links, etc) that are also present.
>
> But how hard would it be to make actual links for all those purposes,
> instead of those widgets?

I found a hack to make the links use the follow-link mechanism, and
have checked it in.

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn'tgovern behavior in Customize]

[Richard Stallman]

    I found a hack to make the links use the follow-link mechanism, and
    have checked it in.

Thanks!

Re: [drew.adams@oracle.com: mouse-1-click-follows-link doesn't govern behavior in Customize]

[Jason Rumney]

Chong Yidong wrote:
> The buttons in the customize buffer are not links; they are buttons.
>   

But there are other links in the customize buffer which are not buttons. 
I think the original report was about (one of) these, though I don't see 
any links on the first line of the buffer, and the link on the third to 
last line with the text `read-quoted-char' appears to be the only link 
in the buffer which DOES respect mouse-1-click-follows-link. The other 
links, which are displayed in link face, seem to act like buttons.

RE: [drew.adams@oracle.com: mouse-1-click-follows-link doesn't govern behavior in Customize]

[Drew Adams]

    > The buttons in the customize buffer are not links; they are buttons.

    I don't see any links on the first line of the buffer,

The link in question is in the first line of the doc for the option.

    and the link on the third to last line with the text
    `read-quoted-char'

Yes, that's the link: 3rd line from the end of the buffer = first line of
the `read-quoted-char-radix' doc.

    appears to be the only link in the buffer
    which DOES respect mouse-1-click-follows-link.

On my build, at least, that link does NOT respect
`mouse-1-click-follows-link':

 GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
 of 2006-07-19 on BOS-CTHEWLAP2
 X server distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-msvc (12.00)'

emacs -Q
M-x set-variable mouse-1-click-follows-link RET nil RET
M-x customize-option read-quoted-char-radix

Click mouse-1 on `read-quoted-char'. The *Help* buffer opens for
`read-quoted-char'.

    The other links,
    which are displayed in link face, seem to act like buttons.

In my build, none of the links respects a nil value of
`mouse-1-click-follows-link', whether the links are displayed in link face,
or, like `read-quoted-char', have no special face. Mouse-1 on any link
follows it.

Perhaps this is a general problem with my build, which has been fixed since
then.