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

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35353 <at> debbugs.gnu.org
Subject: bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name
Date: Mon, 22 Apr 2019 03:58:30 -0700 (PDT)

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

Previous Next

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