[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode n
From: |
Drew Adams |
Subject: |
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.