From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 35353@debbugs.gnu.org, dgutov@yandex.ru
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 [thread overview]
Message-ID: <838sw26u6m.fsf@gnu.org> (raw)
In-Reply-To: <0cba4d18-17d0-4294-a1d4-20cd6d5da49a@default> (message from Drew Adams on Mon, 22 Apr 2019 06:23:23 -0700 (PDT))
> 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.
next prev parent reply other threads:[~2019-04-22 13:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 2:50 bug#35353: 26.2; Buffer *xref*: (1) hard-coded mouse-1, (2) major mode name Drew Adams
2019-04-21 13:27 ` Drew Adams
2019-04-22 9:24 ` Dmitry Gutov
2019-04-22 9:42 ` Eli Zaretskii
2019-04-22 9:48 ` Dmitry Gutov
2019-04-22 10:09 ` Eli Zaretskii
2019-04-22 10:18 ` Dmitry Gutov
2019-04-22 10:21 ` Eli Zaretskii
2019-04-22 10:52 ` Dmitry Gutov
2019-04-22 10:57 ` Dmitry Gutov
2019-04-22 11:42 ` Phil Sainty
2019-04-22 13:08 ` Drew Adams
2019-05-02 22:35 ` Dmitry Gutov
2019-05-02 23:22 ` Drew Adams
2019-05-02 23:31 ` Dmitry Gutov
2019-05-03 0:27 ` Drew Adams
2019-05-04 21:21 ` Richard Stallman
2019-05-04 22:25 ` Drew Adams
2019-05-05 22:50 ` Richard Stallman
2019-05-06 0:40 ` Drew Adams
2019-05-06 8:45 ` Dmitry Gutov
2019-05-06 13:29 ` Drew Adams
2019-05-02 22:48 ` Dmitry Gutov
2019-05-02 23:22 ` Drew Adams
2019-05-02 23:34 ` Dmitry Gutov
2019-05-03 0:27 ` Drew Adams
2019-04-22 11:07 ` Drew Adams
2019-04-22 11:18 ` Eli Zaretskii
2019-04-22 11:30 ` Dmitry Gutov
2019-04-22 11:34 ` Eli Zaretskii
2019-05-02 22:49 ` Dmitry Gutov
2019-05-03 6:38 ` Eli Zaretskii
2020-08-22 14:41 ` Lars Ingebrigtsen
2020-08-22 17:46 ` Drew Adams
[not found] ` <<83v9z6732b.fsf@gnu.org>
2019-04-22 11:07 ` Drew Adams
2019-04-22 11:20 ` Eli Zaretskii
[not found] ` <<<83v9z6732b.fsf@gnu.org>
[not found] ` <<376d5335-eb80-4272-8847-e764242a02b7@default>
[not found] ` <<83r29u70cy.fsf@gnu.org>
2019-04-22 12:23 ` Drew Adams
2019-04-22 13:05 ` Eli Zaretskii
[not found] ` <<<<83v9z6732b.fsf@gnu.org>
[not found] ` <<<376d5335-eb80-4272-8847-e764242a02b7@default>
[not found] ` <<<83r29u70cy.fsf@gnu.org>
[not found] ` <<c1e7f520-7dff-41e0-ba01-9828b87cb703@default>
[not found] ` <<83imv66vi2.fsf@gnu.org>
2019-04-22 13:23 ` Drew Adams
2019-04-22 13:33 ` Eli Zaretskii [this message]
[not found] ` <<83y34273mu.fsf@gnu.org>
2019-04-22 10:58 ` Drew Adams
2022-04-29 12:01 ` Lars Ingebrigtsen
2022-04-29 17:13 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838sw26u6m.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=35353@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).