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

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35353 <at> debbugs.gnu.org
Subject: RE: bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major
 mode name
Date: Sat, 22 Aug 2020 10:46:12 -0700 (PDT)

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

Previous Next

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