bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

Never bothered to use Xref (`dired-do-find-regexp' etc.) until now.
I'm already surprised at what I see within the first 3 minutes.

1. I use `mouse-1-click-follows-link' = nil.  (I use `mouse-2', not
   `mouse-1', to follow clicked links, buttons, etc.)  But this
   setting seems to have no effect in buffer `*xref*'.

   Except by clicking on a file line (it seems), I find it impossible
   to click `mouse-1' without having Emacs follow a link; impossible
   to set point in the buffer using `mouse-1'; no way to just click
   buffer text to select its frame.  What's that all about? 

2. I try `C-h m' or `C-h v major-mode' to find out more about what's
   going on, and I learn that the major mode is called
   `xref--xref-buffer-mode'.  Seriously?  Why?  It seems very wrong
   and unEmacsy to give a major mode an "internal" name.  Users
   examine major modes.  That's part of the usual help system for
   even casual users.

Please respect `mouse-1-click-follows-link'.  And please name the
major mode without an "internal-function" name.  Thx.


In GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
 of 2019-04-13
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor `Microsoft Corp.', version 10.0.17134
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> Please respect `mouse-1-click-follows-link'.

Please contrast what, say, `compile.el' does, which is
simple and Emacs-conventional:

 (define-key map [mouse-2]     'compile-goto-error)
 (define-key map [follow-link] 'mouse-face)

See (elisp) `Key Binding Conventions':

 Many special major modes, like Dired, Info, Compilation,
 and Occur, are designed to handle read-only text that
 contains "hyper-links".

 Such a major mode should redefine 'mouse-2' and <RET> to
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
 follow the links.  It should also set up a 'follow-link'
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 condition, so that the link obeys 'mouse-1-click-follows-link'.

 *Note Clickable Text::.  *Note Buttons::, for an easy
 method of implementing such clickable links.

Each core Emacs developer who defines a major mode with
clickable links should be familiar with and respect this
convention.

Before Emacs distributes a new library - and certainly
before it gives new commands keys that have long been
bound to other commands, especially commands Emacs still
offers - the new library should be vetted to ensure that
it doesn't disregard Emacs conventions.

We'll soon be in release 27.  This bug was introduced in
Emacs 25.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 21.04.2019 16:27, Drew Adams wrote:
>> Please respect `mouse-1-click-follows-link'.
> 
> Please contrast what, say, `compile.el' does, which is
> simple and Emacs-conventional:
> 
>   (define-key map [mouse-2]     'compile-goto-error)
>   (define-key map [follow-link] 'mouse-face)
> 
> See (elisp) `Key Binding Conventions':
> 
>   Many special major modes, like Dired, Info, Compilation,
>   and Occur, are designed to handle read-only text that
>   contains "hyper-links".
> 
>   Such a major mode should redefine 'mouse-2' and <RET> to
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^
>   follow the links.  It should also set up a 'follow-link'
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   condition, so that the link obeys 'mouse-1-click-follows-link'.
> 
>   *Note Clickable Text::.  *Note Buttons::, for an easy
>   method of implementing such clickable links.
> 
> Each core Emacs developer who defines a major mode with
> clickable links should be familiar with and respect this
> convention.

Thank you for the report.

It's not hard to fix, but it seems to do that we'll have to give mouse-2 
a different binding from what it has now. Which is also a breaking 
change (in Xref).

I'd like to let someone else decide whether this is worth it.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 12:24:11 +0300
> 
> It's not hard to fix, but it seems to do that we'll have to give mouse-2 
> a different binding from what it has now. Which is also a breaking 
> change (in Xref).

I'm not sure I follow: currently, mouse-2 does "follow the link"
already, and I believe this bug report will be satisfied if we cause
mouse-1 to do the same when mouse-1-click-follows-link is in effect.
And mouse-1 is not currently bound in Xref buffers.

So how would fixing this constitute a breaking change?

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 12:42, Eli Zaretskii wrote:

> I'm not sure I follow: currently, mouse-2 does "follow the link"
> already,

It calls xref--mouse-2, see xref--button-map.

That function displays the location, but keeps the Xref window selected.

> and I believe this bug report will be satisfied if we cause
> mouse-1 to do the same when mouse-1-click-follows-link is in effect.
> And mouse-1 is not currently bound in Xref buffers.

??

It's bound to xref-goto-xref, see the same map.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Cc: 35353@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 12:48:20 +0300
> 
> On 22.04.2019 12:42, Eli Zaretskii wrote:
> 
> > I'm not sure I follow: currently, mouse-2 does "follow the link"
> > already,
> 
> It calls xref--mouse-2, see xref--button-map.
> 
> That function displays the location, but keeps the Xref window selected.
> 
> > and I believe this bug report will be satisfied if we cause
> > mouse-1 to do the same when mouse-1-click-follows-link is in effect.
> > And mouse-1 is not currently bound in Xref buffers.
> 
> ??
> 
> It's bound to xref-goto-xref, see the same map.

Sorry, I just looked in the manual.

So we already support mouse-1 clicks, don't we?  Or am I again missing
something?

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 13:09, Eli Zaretskii wrote:

> So we already support mouse-1 clicks, don't we?  Or am I again missing
> something?

Yes, but apparently we don't honor mouse-1-click-follows-link.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Cc: 35353@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 13:18:03 +0300
> 
> On 22.04.2019 13:09, Eli Zaretskii wrote:
> 
> > So we already support mouse-1 clicks, don't we?  Or am I again missing
> > something?
> 
> Yes, but apparently we don't honor mouse-1-click-follows-link.

FWIW, I don't see that as a serious issue in this case.  Feel free to
close as wontfix, if you want.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 13:21, Eli Zaretskii wrote:

>>> So we already support mouse-1 clicks, don't we?  Or am I again missing
>>> something?
>>
>> Yes, but apparently we don't honor mouse-1-click-follows-link.
> 
> FWIW, I don't see that as a serious issue in this case.  Feel free to
> close as wontfix, if you want.

The fix is not hard, though. Is the variable more targeted on other use 
cases? Or is it just obscure enough for us not to bother?

The patch looks like this (to be accompanied with an appropriate renaming):

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index e5e59721eb..463f72ae6f 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -722,8 +722,9 @@ xref--next-error-function
  (defvar xref--button-map
    (let ((map (make-sparse-keymap)))
      (define-key map [(control ?m)] #'xref-goto-xref)
-    (define-key map [mouse-1] #'xref-goto-xref)
-    (define-key map [mouse-2] #'xref--mouse-2)
+    (define-key map [follow-link] 'mouse-face)
+    (define-key map [mouse-2] #'xref-goto-xref)
+    (define-key map [mouse-1] #'xref--mouse-2)
      map))

  (defun xref--mouse-2 (event)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 13:52, Dmitry Gutov wrote:
> The patch looks like this

The downside is that the "show location but don't switch windows" action 
becomes harder to invoke: you have to mouse-1 click, wait at least 450ms 
(by default), then release.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Phil Sainty]

On 22/04/19 10:57 PM, Dmitry Gutov wrote:
> The downside is that the "show location but don't switch windows" action
> becomes harder to invoke: you have to mouse-1 click, wait at least 450ms
> (by default), then release.

Perhaps there could be a new user option to choose which of the two
actions should be used by mouse-2 and mouse-1, and then users with
mouse-1-click-follows-link disabled could configure their preferred
action for mouse-2.

In any case, the NEWS will need to point out the change of behaviour,
so it could always suggest custom key bindings which users could employ
to get different behaviour, if that's simplest.


-Phil

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > The downside is that the "show location but don't switch windows" action
> > becomes harder to invoke: you have to mouse-1 click, wait at least 450ms
> > (by default), then release.
> 
> Perhaps there could be a new user option to choose which of the two
> actions should be used by mouse-2 and mouse-1, and then users with
> mouse-1-click-follows-link disabled could configure their preferred
> action for mouse-2.
> 
> In any case, the NEWS will need to point out the change of behaviour,
> so it could always suggest custom key bindings which users could employ
> to get different behaviour, if that's simplest.

What is the "show location but don't switch windows"
action?  Is it `xref--show-location' or some command
that invokes that function?

I don't see (in Emacs 26.2) any mouse action that
shows the location but does not switch windows.  I
see only `C-o' (`xref-show-location-at-point'),
whose name says it does that, but only for point,
not for the mouse position.  (And when I try `C-o'
it too switches to another window, the same as `RET'.)

In any case, how is Xref different from, say, Occur
wrt mouse actions and the general interaction?  What
makes it so special that it should be problematic to
fix this bug?

(Node `Xref Commands' of the Emacs manual calls the
mode "the special XREF mode".  How is it "special"?
Or is that supposed to mean only that it is a child
of `special-mode'?  If that's it then I think this
language will only confuse users, most of whom are
not aware of `special-mode', or at least not thinking
of it here.)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 16:08, Drew Adams wrote:
> What is the "show location but don't switch windows"
> action?  Is it `xref--show-location' or some command
> that invokes that function?

Have you heard of 'C-h k'? It's handy.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > What is the "show location but don't switch windows"
> > action?
> 
> Have you heard of 'C-h k'? It's handy.

How does that answer the question?

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 03.05.2019 2:22, Drew Adams wrote:
>>> What is the "show location but don't switch windows"
>>> action?
>>
>> Have you heard of 'C-h k'? It's handy.
> 
> How does that answer the question?

By helping you to find out the answer for yourself.

Because I have already explained what it does the best I could.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> >>> What is the "show location but don't switch windows"
> >>> action?
> >>
> >> Have you heard of 'C-h k'? It's handy.
> >
> > How does that answer the question?
> 
> By helping you to find out the answer for yourself.

No idea for what key you're suggesting `C-h k' will
tell me what you mean by the "show location but
don't switch windows" action.  Care to share?

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Have you heard of 'C-h k'? It's handy.

  > How does that answer the question?

You type C-h k and then generate some event, and it shows what command
that event will run.  That might enable you to find the answer
to your question:

  > > > What is the "show location but don't switch windows"
  > > > action?

So the answer was helpful, or at least had a good chance of being
helpful.  But the way it was written,

  > > Have you heard of 'C-h k'? It's handy.

is not very helpful, because it made you figure out, or guess,
how it related to your question.  It was teasing.

It is kinder to answer in a way that shows explicitly how the
answer relates to the question.  For instance, 

  C-h k followed by generating the event should tell  you
  what command it runs.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

>   > > Have you heard of 'C-h k'? It's handy.
>   > How does that answer the question?
> 
> You type C-h k and then generate some event, and it shows what command
> that event will run.  That might enable you to find the answer
> to your question:
>   > > > What is the "show location but don't switch windows"
>   > > > action?
> 
> So the answer was helpful, or at least had a good chance of being
> helpful.

No, it didn't help at all.  I had no idea what
action the description "show location but don't
switch windows" was meant to indicate.

And no particular key was mentioned, so I had
no idea how `C-h k' could possibly have helped.
And none of the keys mentioned exhibited any "show
location but don't switch windows" behavior.

(And yes, I am aware of `C-h k'.)

> But the way it was written,
>   > > Have you heard of 'C-h k'? It's handy.
> is not very helpful, because it made you figure out, or guess,
> how it related to your question.  It was teasing.

It was just a snide remark, not helpful at all.
 
> It is kinder to answer in a way that shows explicitly how the
> answer relates to the question.  For instance,
>   C-h k followed by generating the event should tell  you
>   what command it runs.

No such event/key was ever identified, so
`C-h k' really did not help here in any way.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No such event/key was ever identified, so
  > `C-h k' really did not help here in any way.

If it doesn't tell you a command name, perhaps this case is a deficiency
in C-h k itself.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > No such event/key was ever identified, so
> > `C-h k' really did not help here in any way.
> 
> If it doesn't tell you a command name, perhaps
> this case is a deficiency in C-h k itself.

You are misunderstanding, I think.  Please look at
the bug thread if you are really interested.

It was Dmitry (not `C-h k') who never identified
the key for which to use `C-h k'.  He never
identified the command either.  No idea what he
was (not) talking about.

The only thing he did was refer to an unidentified
"show location but don't switch windows" behavior.
When I asked what he meant by that he just asked me
sarcastically if I've heard of `C-h k'.  Not helpful.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 06.05.2019 3:40, Drew Adams wrote:
> It was Dmitry (not `C-h k') who never identified
> the key for which to use `C-h k'.  He never
> identified the command either.

If that really was the issue: the "show location but don't switch 
windows" command is xref--mouse-2, currently bound to mouse-2.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > It was Dmitry (not `C-h k') who never identified
> > the key for which to use `C-h k'.  He never
> > identified the command either.
> 
> If that really was the issue: the "show location but don't switch
> windows" command is xref--mouse-2, currently bound to mouse-2.

Thank you.  That was the question about your "show
location but don't switch windows".  (It was not
the issue reported in the bug report, however.)

But as I mentioned, with the settings I cited
there is no difference in behavior between mouse-1
and mouse-2.  Each shows the target in the other
window, without selecting that window.

And unfortunately the window the target is shown
in is the window the Dired buffer was in - the
Dired buffer is replaced there (not a good thing,
IMO).

Anyway, I've already said all that.  But thanks
for clearing up what you meant by the "show
location but don't switch windows" command.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 16:08, Drew Adams wrote:
> I
> see only `C-o' (`xref-show-location-at-point'),
> whose name says it does that, but only for point,
> not for the mouse position.  (And when I try `C-o'
> it too switches to another window, the same as `RET'.)

It doesn't do that over here.

> In any case, how is Xref different from, say, Occur
> wrt mouse actions and the general interaction?  What
> makes it so special that it should be problematic to
> fix this bug?

Honestly, it's quite easy. I'm pasting the code patch below.

Would you write the NEWS entry for it? And any necessary manual changes 
would be nice as well.

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index c7f015b94f..6dcdd75c84 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -722,8 +722,9 @@ xref--next-error-function
  (defvar xref--button-map
    (let ((map (make-sparse-keymap)))
      (define-key map [(control ?m)] #'xref-goto-xref)
-    (define-key map [mouse-1] #'xref-goto-xref)
-    (define-key map [mouse-2] #'xref--mouse-2)
+    (define-key map [follow-link] 'mouse-face)
+    (define-key map [mouse-2] #'xref-goto-xref)
+    (define-key map [mouse-3] #'xref--mouse-3)
      map))

  (defun xref--mouse-2 (event)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > I see only `C-o' (`xref-show-location-at-point'),
> > whose name says it does that, but only for point,
> > not for the mouse position.  (And when I try `C-o'
> > it too switches to another window, the same as `RET'.)
> 
> It doesn't do that over here.

Over here meaning what?  Which sentence are you
referencing: mouse position or window switching?

Do you have non-nil `pop-up-frames'?  Are buffers
named `*...*' special-display buffers for you?

Yes, I was describing what I see in my setup,
which has those things.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 03.05.2019 2:22, Drew Adams wrote:

>> It doesn't do that over here.
> 
> Over here meaning what?  Which sentence are you
> referencing: mouse position or window switching?

Doesn't switch to another window.

> Do you have non-nil `pop-up-frames'?

Nope, but that doesn't seem to affect the non-window-switching.

> Are buffers
> named `*...*' special-display buffers for you?

No idea what that means.

> Yes, I was describing what I see in my setup,
> which has those things.

And I'm describing 'emacs -Q'. If you see some details in the 
implementation that could work more reliably (e.g. with your 
configuration as well), please go ahead and point them out.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> >> It doesn't do that over here.
> >
> > Over here meaning what?  Which sentence are you
> > referencing: mouse position or window switching?
> 
> Doesn't switch to another window.
> 
> > Do you have non-nil `pop-up-frames'?
> 
> Nope, but that doesn't seem to affect the non-window-switching.
> 
> > Are buffers named `*...*' special-display buffers for you?
>
> No idea what that means.

Customize option `special-display-regexps' to
`("[ ]?[*][^*]+[*]")', for example.

> > Yes, I was describing what I see in my setup,
> > which has those things.
> 
> And I'm describing 'emacs -Q'.

I just reported the bug.  If you want to fix it, fine.
If not, OK.  I'm not a user of xref, so far.  I simply
tried it and immediately fell upon the problem reported.

I have nil `mouse-1-click-follows-link', non-nil
`pop-up-frames', and `("[ ]?[*][^*]+[*]")' for
`special-display-regexps' (which affects a buffer named
`*xref*').

If the bug report helps, great.  If you apply the fix
I suggested (from the manual, about Emacs conventions,
and shown as example for `compile.el'), fine.  If you
apply some other fix, fine.  If you leave it as is, too
bad for some xref users, probably.  Or maybe someone
else will fix it later.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> >>> So we already support mouse-1 clicks, don't we?  Or am I again missing
> >>> something?
> >>
> >> Yes, but apparently we don't honor mouse-1-click-follows-link.
> >
> > FWIW, I don't see that as a serious issue in this case.  Feel free to
> > close as wontfix, if you want.
> 
> The fix is not hard, though. Is the variable more targeted on other use
> cases? Or is it just obscure enough for us not to bother?

The variable is not obscure at all.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Cc: 35353@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 13:52:17 +0300
> 
> On 22.04.2019 13:21, Eli Zaretskii wrote:
> 
> > FWIW, I don't see that as a serious issue in this case.  Feel free to
> > close as wontfix, if you want.
> 
> The fix is not hard, though. Is the variable more targeted on other use 
> cases? Or is it just obscure enough for us not to bother?
> 
> The patch looks like this (to be accompanied with an appropriate renaming):

I'm not against fixing this if the fix is easy and doesn't have
unpleasant consequences.

Thanks.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 14:18, Eli Zaretskii wrote:

>> The patch looks like this (to be accompanied with an appropriate renaming):
> 
> I'm not against fixing this if the fix is easy and doesn't have
> unpleasant consequences.

It takes us the mouse-2 binding? But I guess we could move it to mouse-3?

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Cc: 35353@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 14:30:37 +0300
> 
> On 22.04.2019 14:18, Eli Zaretskii wrote:
> 
> >> The patch looks like this (to be accompanied with an appropriate renaming):
> > 
> > I'm not against fixing this if the fix is easy and doesn't have
> > unpleasant consequences.
> 
> It takes us the mouse-2 binding? But I guess we could move it to mouse-3?

To tell the truth, I fail to see how mouse-2 and mouse-1 are different
in the default configuration.  (They are bound to different commands,
but the effect is the same, AFAICT.)

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Dmitry Gutov]

On 22.04.2019 14:34, Eli Zaretskii wrote:
> To tell the truth, I fail to see how mouse-2 and mouse-1 are different
> in the default configuration.  (They are bound to different commands,
> but the effect is the same, AFAICT.)

The difference is in which window ends up being selected. Maybe it's not 
hugely important, though (I don't remember the last time I used mouse-2 
for this purpose).

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Cc: 35353@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 May 2019 01:49:31 +0300
> 
> On 22.04.2019 14:34, Eli Zaretskii wrote:
> > To tell the truth, I fail to see how mouse-2 and mouse-1 are different
> > in the default configuration.  (They are bound to different commands,
> > but the effect is the same, AFAICT.)
> 
> The difference is in which window ends up being selected.

Oh, you mean one of them also selects the XREF buffer's window.  Yes,
I see it now, thanks.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> The fix is not hard, though. Is the variable more targeted on other
> use cases? Or is it just obscure enough for us not to bother?
>
> The patch looks like this (to be accompanied with an appropriate renaming):

[...]

> -    (define-key map [mouse-1] #'xref-goto-xref)
> -    (define-key map [mouse-2] #'xref--mouse-2)
> +    (define-key map [follow-link] 'mouse-face)
> +    (define-key map [mouse-2] #'xref-goto-xref)
> +    (define-key map [mouse-1] #'xref--mouse-2)

I think that this is basically what most modes that have clickable stuff
do, so I think it might be the right solution for xref, too (even if
xref doesn't have buttons per se).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > -    (define-key map [mouse-1] #'xref-goto-xref)
> > -    (define-key map [mouse-2] #'xref--mouse-2)
> > +    (define-key map [follow-link] 'mouse-face)
> > +    (define-key map [mouse-2] #'xref-goto-xref)
> > +    (define-key map [mouse-1] #'xref--mouse-2)
> 
> I think that this is basically what most modes that have clickable stuff
> do, so I think it might be the right solution for xref, too (even if
> xref doesn't have buttons per se).

IOW, your conclusion is "Won't fix".

That is not what most modes that have links do.

Most such modes have `down-mouse-1' do
`mouse-drag-region' and `mouse-1' do `mouse-set-point'.

For users who want `mouse-1' to follow a link, it
is option `mouse-1-click-follows-link' that takes
care of that.  And even when that is non-nil, a
user can set point with `mouse-1', by simply holding
`mouse-1' pressed more than 450 milliseconds.

That's the behavior that's requested here - the USUAL
Emacs behavior for `mouse-1' on links.  Nothing more.

This is nothing new, nothing unusual.  What's unusual
is the xref behavior.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > > So we already support mouse-1 clicks, don't we?  Or am I again missing
> > > something?
> >
> > Yes, but apparently we don't honor mouse-1-click-follows-link.
> 
> FWIW, I don't see that as a serious issue in this case.  Feel free to
> close as wontfix, if you want.

Seriously?  Mouse-2 was the original way to follow
links.  And ubiquitously in Emacs users need to be
able to set point.  They should be able to do so
using `mouse-1'.

We have `mouse-1-click-follows-link' for a reason.
Why should this be the only place (AFAIK) in Emacs
where it is not respected?  Any user who uses nil
for that option will find Xref unusable.

Not to mention that this violates the explicit Emacs
convention (cited earlier).

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Date: Mon, 22 Apr 2019 04:07:54 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 35353@debbugs.gnu.org
> 
> > > > So we already support mouse-1 clicks, don't we?  Or am I again missing
> > > > something?
> > >
> > > Yes, but apparently we don't honor mouse-1-click-follows-link.
> > 
> > FWIW, I don't see that as a serious issue in this case.  Feel free to
> > close as wontfix, if you want.
> 
> Seriously?  Mouse-2 was the original way to follow
> links.  And ubiquitously in Emacs users need to be
> able to set point.  They should be able to do so
> using `mouse-1'.

FWIW, I see no important reasons to set point in XREF buffers by
clicking the mouse.

> Not to mention that this violates the explicit Emacs
> convention (cited earlier).

It doesn't, your citation is not necessarily relevant to the issue at
hand.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > > FWIW, I don't see that as a serious issue in this case.  Feel free to
> > > close as wontfix, if you want.
> >
> > Seriously?  Mouse-2 was the original way to follow
> > links.  And ubiquitously in Emacs users need to be
> > able to set point.  They should be able to do so
> > using `mouse-1'.
> 
> FWIW, I see no important reasons to set point in XREF buffers by
> clicking the mouse.

It's always important to be able to set point by
clicking the mouse.

That's the reason why even when `mouse-1' follows
a link we let users instead set point using `mouse-1'
by just holding it pressed longer before releasing it.

And it's the reason we have option
`mouse-1-click-follows-link': to let users not have
`mouse-1' follow links with a non-slow click.

And it's the reason the manual establishes the
convention.  As it says (quoted more extensively
earlier):

 Many special major modes, like Dired, Info, Compilation,
 and Occur, are designed to handle read-only text that
 contains "hyper-links".

It is precisely in these contexts - of which buffer
*xref* is one, that it is important to respect option
`mouse-1-click-follows-link'.

That's the point of that passage.  Users need to be
able to follow links, but they also need to be able
to set point.  How they do one or the other is
decided by their individual preference, using option
`mouse-1-click-follows-link'.

And I pointed out in the original report specifically
how the bug is a problem for users with the option nil:

It's impossible to click `mouse-1' anywhere inside the
window to select it, set point, and focus its frame
(unless you can find and click the file line preceding
a boatload of links - and that line might even be
outside the window, in which case you're completely
out of luck).

> > Not to mention that this violates the explicit Emacs
> > convention (cited earlier).
> 
> It doesn't, your citation is not necessarily relevant to the issue at
> hand.

Why do you think so?  I think it is exactly relevant -
see above.

Do you think that buffer *xref* is different in this
regard from Dired, compilation, or Occur buffers?
How so?  These are buffers that are dense with links,
making it important that users can use the mouse not
only to follow links but also to set point.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Date: Mon, 22 Apr 2019 05:23:17 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 35353@debbugs.gnu.org
> 
> > FWIW, I see no important reasons to set point in XREF buffers by
> > clicking the mouse.
> 
> It's always important to be able to set point by
> clicking the mouse.

I disagree.  And it's easy to disagree, because you didn't provide any
rationale, none at all.

> Do you think that buffer *xref* is different in this
> regard from Dired, compilation, or Occur buffers?
> How so?  These are buffers that are dense with links,
> making it important that users can use the mouse not
> only to follow links but also to set point.

There are no links in the XREF buffer, not really.  This buffer is an
aid to select on of several possible symbols, that's all.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > > FWIW, I see no important reasons to set point in XREF buffers by
> > > clicking the mouse.
> >
> > It's always important to be able to set point by
> > clicking the mouse.
> 
> I disagree.  And it's easy to disagree, because you didn't provide any
> rationale, none at all.

Of course I did - more than one, and more than once now.
Click a mouse button to set point, select a window, and
focus its frame.  Is that not enough rationale for you?

I find it really hard to believe that this is not
obvious to you.

Surely you used a mouse with Emacs before we
switched the default behavior to having mouse-1,
not mouse-2, follow links?  And surely you've
accidentally clicked mouse-1 on a link (e.g. in
Dired) when all you wanted to do was select the
window?

In any case, surely you do realize or can
imagine that at least some Emacs users set
`mouse-1-click-follows-link' to nil?  Surely
you can imagine that removing the effect of
that setting for *xref* buffers could be
upsetting and surprising to them, no?

> > Do you think that buffer *xref* is different in this
> > regard from Dired, compilation, or Occur buffers?
> > How so?  These are buffers that are dense with links,
> > making it important that users can use the mouse not
> > only to follow links but also to set point.
> 
> There are no links in the XREF buffer, not really.  This buffer is an
> aid to select on of several possible symbols, that's all.

Sigh.

The "non-links" have `mouse-face'. They have a `keymap'
property that binds `mouse-1' and `mouse-2' to commands
that follow the "non-link" to its location.  They have
`:help-echo' that says "mouse-2: display in another
window, RET or mouse-1: follow reference".  When you
click them or hit RET or C-o they sure seem to follow
the "non-links".  What am I missing?

Using `A' In Dired puts me in an *xref* buffer.  Using
the "non-links" in that buffer do NOT, in any way that
I can imagine you might mean, "select on[e] of possible
symbols".

I can follow these "non-links", but I'm really having
trouble following you.  And the problem (this bug) is
that I cannot NOT follow these "non-links".

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Eli Zaretskii]

> Date: Mon, 22 Apr 2019 06:23:23 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 35353@debbugs.gnu.org
> 
> > > > FWIW, I see no important reasons to set point in XREF buffers by
> > > > clicking the mouse.
> > >
> > > It's always important to be able to set point by
> > > clicking the mouse.
> > 
> > I disagree.  And it's easy to disagree, because you didn't provide any
> > rationale, none at all.
> 
> Of course I did - more than one, and more than once now.
> Click a mouse button to set point, select a window, and
> focus its frame.  Is that not enough rationale for you?

No.  You are talking in general, whereas I'm talking specifically
about windows showing the XREF buffer.

> In any case, surely you do realize or can
> imagine that at least some Emacs users set
> `mouse-1-click-follows-link' to nil?  Surely
> you can imagine that removing the effect of
> that setting for *xref* buffers could be
> upsetting and surprising to them, no?

There's plenty of spaces where mouse-1 does nothing like
mouse-1-click-follows-link suggests.  This is one of them.

Mind you, I don't object to making XREF behave similarly, I just don't
think it's terribly important.  As I already said too many times.  I
really hope you finally decide to agree to disagree.

> The "non-links" have `mouse-face'. They have a `keymap'
> property that binds `mouse-1' and `mouse-2' to commands
> that follow the "non-link" to its location.  They have
> `:help-echo' that says "mouse-2: display in another
> window, RET or mouse-1: follow reference".  When you
> click them or hit RET or C-o they sure seem to follow
> the "non-links".  What am I missing?
> 
> Using `A' In Dired puts me in an *xref* buffer.  Using
> the "non-links" in that buffer do NOT, in any way that
> I can imagine you might mean, "select on[e] of possible
> symbols".
> 
> I can follow these "non-links", but I'm really having
> trouble following you.  And the problem (this bug) is
> that I cannot NOT follow these "non-links".

Of course you can follow them: mouse-1 already follows them (as does
mouse-2).  We are not talking about following them, we are talking
about something else.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Drew Adams]

> > > I'm not sure I follow: currently, mouse-2 does "follow the link"
> > > already,
> >
> > It calls xref--mouse-2, see xref--button-map.
> > That function displays the location, but keeps the Xref window selected.
> >
> > > and I believe this bug report will be satisfied if we cause
> > > mouse-1 to do the same when mouse-1-click-follows-link is in effect.
> > > And mouse-1 is not currently bound in Xref buffers.
> >
> > ?? It's bound to xref-goto-xref, see the same map.
> 
> Sorry, I just looked in the manual.
> So we already support mouse-1 clicks, don't we?
> Or am I again missing something?

What do you mean by "support mouse-1 clicks"?
We support them following a link, but we don't
support them not following a link.

`mouse-1' clicks follow the link, regardless of
`mouse-1-click-follows-link'.  When that variable
is nil a `mouse-1' click should not follow a link.

In the nil case it should typically (default
behavior) just set point (or begin a region drag) -
`mouse-drag-region' for `down-mouse-1' and
`mouse-set-point' for `mouse-1'.

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Lars Ingebrigtsen]

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

> 1. I use `mouse-1-click-follows-link' = nil.  (I use `mouse-2', not
>    `mouse-1', to follow clicked links, buttons, etc.)  But this
>    setting seems to have no effect in buffer `*xref*'.
>
>    Except by clicking on a file line (it seems), I find it impossible
>    to click `mouse-1' without having Emacs follow a link; impossible
>    to set point in the buffer using `mouse-1'; no way to just click
>    buffer text to select its frame.  What's that all about? 

I've now fixed this in Emacs 29.

> 2. I try `C-h m' or `C-h v major-mode' to find out more about what's
>    going on, and I learn that the major mode is called
>    `xref--xref-buffer-mode'.  Seriously?  Why?  It seems very wrong
>    and unEmacsy to give a major mode an "internal" name.  Users
>    examine major modes.  That's part of the usual help system for
>    even casual users.

That is pretty unusual naming for a major mode, but I don't think it's
worth changing at this point.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name

[Juri Linkov]

>> 1. I use `mouse-1-click-follows-link' = nil.  (I use `mouse-2', not
>>    `mouse-1', to follow clicked links, buttons, etc.)  But this
>>    setting seems to have no effect in buffer `*xref*'.
>>
>>    Except by clicking on a file line (it seems), I find it impossible
>>    to click `mouse-1' without having Emacs follow a link; impossible
>>    to set point in the buffer using `mouse-1'; no way to just click
>>    buffer text to select its frame.  What's that all about? 
>
> I've now fixed this in Emacs 29.

It seems this is unnecessary:

    (when mouse-1-click-follows-link
      (define-key map [mouse-1] #'xref-goto-xref))

because `[follow-link]' takes care about handling `mouse-1-click-follows-link'.