[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: |
Eli Zaretskii |
Subject: |
bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name |
Date: |
Mon, 22 Apr 2019 16:33:37 +0300 |
> 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, (continued)
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Eli Zaretskii, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Dmitry Gutov, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Eli Zaretskii, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Eli Zaretskii, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Eli Zaretskii, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name,
Eli Zaretskii <=
- bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name, Drew Adams, 2019/04/22