* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] [not found] <001a01c883a2$b94cae10$0600a8c0@us.oracle.com> @ 2011-07-06 17:24 ` Lars Magne Ingebrigtsen 2011-07-06 17:32 ` Drew Adams 2011-07-06 20:09 ` Stefan Monnier 2011-10-27 21:13 ` bug#52: FW: bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Drew Adams 1 sibling, 2 replies; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-06 17:24 UTC (permalink / raw) To: Drew Adams; +Cc: 52 "Drew Adams" <drew.adams@oracle.com> writes: > These are links. They should be controlled by `mouse-1-click-follows-link'. [...] >> Click mouse-1 on a link in a Customize buffer that is a link to >> another option name or similar. That is, on text between `' that is >> highlighted with mouseover (`mouse-face'). The link is followed. >> >> The link should not be followed by `mouse-1' if >> `mouse-1-click-follows-link' is nil. In that case, only clicking >> `mouse-2' should follow the link. That sounds logical. The actual key binding in these buffers for the mouse is: <down-mouse-1> widget-button-click <down-mouse-2> widget-button-click How is `mouse-1-click-follows-link' generally supposed to work? Is `widget-button-click' supposed to not do its thing if `mouse-1-click-follows-link' is nil? That seems rather yucky. Or is the mode not supposed to bind `down-mouse-1' to anything if it's nil? That variable is unknown to me. The documentation says: ------ This feature only works in modes that specifically identify clickable text as links, so it may not work with some external packages. See `mouse-on-link-p' for details. ------ Customize can't be said to be an "external package". :-) `mouse-on-link-p' says: ------ A clickable link is identified by one of the following methods: - If the character at POS has a non-nil `follow-link' text or overlay property, the value of that property determines what to do. - If there is a local key-binding or a keybinding at position POS for the `follow-link' event, the binding of that event determines what to do. ------ And the widget stuff does put `follow-link' on stuff. So how is this supposed to tie together? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] 2011-07-06 17:24 ` bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Lars Magne Ingebrigtsen @ 2011-07-06 17:32 ` Drew Adams 2011-07-06 20:09 ` Stefan Monnier 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2011-07-06 17:32 UTC (permalink / raw) To: 'Lars Magne Ingebrigtsen'; +Cc: 52 Thanks for looking at this, Lars. I'm no expert on how this works or is supposed to work. A (blind) guess would be that the problem is that these are perhaps not considered to be "links" by the Customize code. Dunno. Emacs can be fussy about what it considers to be a link. Some of the things called "buttons" in the code are in fact links from a user viewpoint. (But some of them are not - they are truly action buttons.) Someone more knowledgable than I will need to help here, I'm afraid. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] 2011-07-06 17:24 ` bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Lars Magne Ingebrigtsen 2011-07-06 17:32 ` Drew Adams @ 2011-07-06 20:09 ` Stefan Monnier 2011-07-07 16:19 ` Lars Magne Ingebrigtsen 2011-07-07 19:03 ` Chong Yidong 1 sibling, 2 replies; 13+ messages in thread From: Stefan Monnier @ 2011-07-06 20:09 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 52 >>> Click mouse-1 on a link in a Customize buffer that is a link to >>> another option name or similar. That is, on text between `' that is >>> highlighted with mouseover (`mouse-face'). The link is followed. Yes, Custom has always used mouse-1 clicks for that purpose, AFAIK. > The actual key binding in these buffers for the mouse is: > <down-mouse-1> widget-button-click > <down-mouse-2> widget-button-click > How is `mouse-1-click-follows-link' generally supposed to work? Is This is supposed to let mouse-1 clicks follow links otherwise only accessible via mouse-2 clicks (i.e. when there's no binding for mouse-1 on this button/link). It relies on the `follow-link' text-property and/or key binding to specifies when this fallback is applicable. That was introduced in reaction to people complaining about the non-standard Emacs convention of using mouse-2 to follow links. But actually some part of Emacs already used mouse-1 to follow links, such as Customize, so these aren't affected by mouse-1-click-follows-link. I think in this present case, Custom should better follow Emacs conventions and hence only bind mouse-2 and then rely on the follow-link feature to make mouse-1 also work for those users who like it. Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] 2011-07-06 20:09 ` Stefan Monnier @ 2011-07-07 16:19 ` Lars Magne Ingebrigtsen 2011-07-07 19:03 ` Chong Yidong 1 sibling, 0 replies; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-07 16:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: 52 Stefan Monnier <monnier@iro.umontreal.ca> writes: > I think in this present case, Custom should better follow Emacs > conventions and hence only bind mouse-2 and then rely on the follow-link > feature to make mouse-1 also work for those users who like it. That sounds like a good idea. I've had a go at doing this, but I'm afraid I wasn't able to make it work. Somebody who knows more about `follow-link' and customize should have a look at it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] 2011-07-06 20:09 ` Stefan Monnier 2011-07-07 16:19 ` Lars Magne Ingebrigtsen @ 2011-07-07 19:03 ` Chong Yidong 2011-10-27 21:16 ` Drew Adams 1 sibling, 1 reply; 13+ messages in thread From: Chong Yidong @ 2011-07-07 19:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Magne Ingebrigtsen, 52 The original report concerned only Emacs 22: >> Click mouse-1 on a link in a Customize buffer that is a link to >> another option name or similar. That is, on text between `' that is >> highlighted with mouseover (`mouse-face'). The link is followed. >> >> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) >> of 2007-06-02 on RELEASE Since Emacs 23, links in the Customize buffer have obeyed mouse-1-click-follows-link, via custom-mode-link-map. The other widget buttons used by Customize, like the Exit button, are always activated with mouse-1, regardless of mouse-1-click-follows-link. But this is the correct behavior, since those are not links. So this is a zombie bug report. I'm closing it. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] 2011-07-07 19:03 ` Chong Yidong @ 2011-10-27 21:16 ` Drew Adams 2011-10-27 21:28 ` bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2011-10-27 21:16 UTC (permalink / raw) To: 'Chong Yidong', 'Stefan Monnier' Cc: 'Lars Magne Ingebrigtsen', 52 Well, it turns out that that is no solution anyway. If I do that then even the real buttons (the rectangular, raised ones) in Customize do not react to mouse-1. Sigh. Why are links treated the same as buttons in Customize? Maybe that's the question. Dunno. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] 2011-10-27 21:16 ` Drew Adams @ 2011-10-27 21:28 ` Drew Adams 2011-10-29 4:46 ` Chong Yidong 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2011-10-27 21:28 UTC (permalink / raw) To: 'Chong Yidong', 'Stefan Monnier'; +Cc: 52 > Well, it turns out that that is no solution anyway. If I do > that then even the real buttons (the rectangular, raised ones) > in Customize do not react to mouse-1. > > Sigh. > > Why are links treated the same as buttons in Customize? > Maybe that's the question. Dunno. I want, as before, links to work only with mouse-2, but buttons and menu items to work with mouse-1. It seems that's no longer possible (?). Using the hook I showed, I can use mouse-2 (only) for links (buttons too, unfortunately), but it seems that mouse-1 (only) is hard-coded for menu items. So I can use mouse-2 on the State button to open its menu, but then must switch to mouse-1 to choose a menu item. I want to be able to select text normally using mouse-1 and mouse-3 etc., including text that is linked. I want to be able to click mouse-2 (only) to follow links. I want to be able to use mouse-1 for both buttons and menu items. This is nuts. Why is it so messy? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] 2011-10-27 21:28 ` bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] Drew Adams @ 2011-10-29 4:46 ` Chong Yidong 2011-10-29 15:04 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Chong Yidong @ 2011-10-29 4:46 UTC (permalink / raw) To: Drew Adams; +Cc: 52 "Drew Adams" <drew.adams@oracle.com> writes: > I want to be able to select text normally using mouse-1 and mouse-3 > etc., including text that is linked. Nothing prevents you from doing this. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] 2011-10-29 4:46 ` Chong Yidong @ 2011-10-29 15:04 ` Drew Adams 2011-10-30 3:25 ` Chong Yidong 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2011-10-29 15:04 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 52 > > I want to be able to select text normally using mouse-1 and mouse-3 > > etc., including text that is linked. > > Nothing prevents you from doing this. Yeah, how? See what I wrote. `mouse-1', held down for no matter how long, follows links and buttons in Customize. It does not do this anywhere outside of Customize. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] 2011-10-29 15:04 ` Drew Adams @ 2011-10-30 3:25 ` Chong Yidong 2011-10-30 14:46 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Chong Yidong @ 2011-10-30 3:25 UTC (permalink / raw) To: Drew Adams; +Cc: 52 "Drew Adams" <drew.adams@oracle.com> writes: >> >> Nothing prevents you from doing this. > > Yeah, how? See what I wrote. `mouse-1', held down for no matter how > long, follows links and buttons in Customize. It does not do this > anywhere outside of Customize. I can't reproduce this. With emacs -Q, and doing M-x customize, dragging `mouse-1' across (say) the "Undo edits" buffer selects that text, without enabling the button. Similarly for links. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] 2011-10-30 3:25 ` Chong Yidong @ 2011-10-30 14:46 ` Drew Adams 2012-09-17 0:26 ` bug#52: FW: [mouse-1 in Customize shouldrespectmouse-1-click-follows-link] Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2011-10-30 14:46 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 52 > I can't reproduce this. With emacs -Q, and doing M-x customize, > dragging `mouse-1' across (say) the "Undo edits" buffer selects that > text, without enabling the button. I see that too for emacs -Q. So what? 1. _Clicking_, not dragging, mouse-1 on `Undo edits' or `INS' or `State' _does_ activate the button. No matter how long you hold mouse-1 depressed. `mouse-1-click-follows-links' is supposed to affect mouse-1 clicks, and a nil value is supposed to return you to the same (sane) behavior Emacs had before Dev started making mouse-1 follow links at all. > Similarly for links. No again. In emacs -Q, with nil `mouse-1-click-follows-link', press mouse-1 on `Hide' and hold it there as long or as short a time as you like (without dragging). The `Hide' "link" is still followed (or the "button" is activated) when you release the button. Mouse-1 click is following links, in spite of the option value. 2. To reproduce the problem as I reported it in doc strings, with emacs -Q: (setq mouse-1-click-follows-link nil) (defcustom foo-fns () "Some possibilities: `foobar', `toto'" :type '(repeat symbol) :group 'edit) (defun foobar () "Foobar's doc string" 42) M-x customize-option foo-fns In the doc string, `foobar' is highlighted when you mouseover it. It is a link. Click mouse-1 on it (you might sometimes have to click twice, but not a double-click). Help opens. QED. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: [mouse-1 in Customize shouldrespectmouse-1-click-follows-link] 2011-10-30 14:46 ` Drew Adams @ 2012-09-17 0:26 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-09-17 0:26 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 52 ping ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#52: FW: bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] [not found] <001a01c883a2$b94cae10$0600a8c0@us.oracle.com> 2011-07-06 17:24 ` bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Lars Magne Ingebrigtsen @ 2011-10-27 21:13 ` Drew Adams 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2011-10-27 21:13 UTC (permalink / raw) To: 52 > From: Chong Yidong Sent: Thursday, July 07, 2011 12:03 PM > > Since Emacs 23, links in the Customize buffer have obeyed > mouse-1-click-follows-link, via custom-mode-link-map. So it's a regression starting in Emacs 23. ;-) Actually, the binding is made in `widget-keymap', which is the grandparent of `custom-mode-link-map'. But I thought anyway, from looking at the code, that `custom-mode-link-map' would be the right one to adjust, to change behavior for this. But apparently I was wrong - see below. > The other widget buttons used by Customize, like the Exit button, are > always activated with mouse-1, regardless of > mouse-1-click-follows-link. But this is the correct behavior, > since those are not links. > > So this is a zombie bug report. I'm closing it. You don't give users the choice (easily). They should be able to control this via `mouse-1-click-follows-link'. They should not have to also modify `custom-mode-link-map' (or, in face, `widget-keymap') directly. Help buffers have links on function names etc. Mouse-1 on those links respects `mouse-1-click-follows-link'. My code adds links also to function names etc. in Customize doc strings - same idea as Help. Those too should respect the user option. It's not even clear to me how to control this. I tried this at first: (add-hook 'Custom-mode-hook (lambda () (define-key custom-mode-link-map [mouse-1] 'mouse-set-point) (define-key custom-mode-link-map [down-mouse-1] 'mouse-drag-region))) And it didn't work, but I'm not sure why (still). Keymap `custom-mode-link-map' correctly had this: <down-mouse-1> mouse-drag-region <mouse-1> mouse-set-point But clicking mouse-1 on link/button text had this effect: As soon as mouse-1 was pressed (not released), the face changed to an inset (depressed) face. And as soon as mouse-1 was released, the link was followed (and the face restored). The inset face looks like `custom-button-pressed', the local value of `widget-button-pressed-face', and `widget-button-click' was in fact called (why?). The debugger said that `widget-button-click' was called interactively (but it is not bound to any key). If I did `C-u C-x =' on a link, the help said that the keymap property was nil, the follow-link property was `mouse-face', and the button property was `documentation-link (widget)Top'. And mouse-1 was still bound to `mouse-set-point', etc.! And it didn't matter whether the click was quick or I held mouse-1 depressed for a while (to wait out some timeout). Actually, if I did something in another app and then came back and clicked mouse-1 on a link, the first click _sometimes_ did nothing but set point, but thereafter the other behavior returned (depressed-button face, follow link etc.). This behavior is still a mystery to me. I eventually got it done by binding the mouse keys in `widget-keymap' instead of `custom-mode-link-map' in the hook. Why I would need to do that, I have no idea. Do you have an idea? What's clear is that it is not very clear how a user can easily prevent mouse-1 from following such links in Customize. And I still don't understand why you don't let the option `mouse-1-click-follows-link' control this, just as it does in all other buffers. Why should Customize be handled differently from *Help* etc.? ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-09-17 0:26 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <001a01c883a2$b94cae10$0600a8c0@us.oracle.com>
2011-07-06 17:24 ` bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Lars Magne Ingebrigtsen
2011-07-06 17:32 ` Drew Adams
2011-07-06 20:09 ` Stefan Monnier
2011-07-07 16:19 ` Lars Magne Ingebrigtsen
2011-07-07 19:03 ` Chong Yidong
2011-10-27 21:16 ` Drew Adams
2011-10-27 21:28 ` bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] Drew Adams
2011-10-29 4:46 ` Chong Yidong
2011-10-29 15:04 ` Drew Adams
2011-10-30 3:25 ` Chong Yidong
2011-10-30 14:46 ` Drew Adams
2012-09-17 0:26 ` bug#52: FW: [mouse-1 in Customize shouldrespectmouse-1-click-follows-link] Drew Adams
2011-10-27 21:13 ` bug#52: FW: bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link] Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).