[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xref and displaying locations in appropriate window or frame
From: |
Eli Zaretskii |
Subject: |
Re: xref and displaying locations in appropriate window or frame |
Date: |
Sun, 24 Jan 2016 19:58:57 +0200 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 24 Jan 2016 20:27:29 +0300
>
> On 01/24/2016 06:43 PM, Eli Zaretskii wrote:
>
> >> xref-find-definitions has a family of commands (namely -other-window and
> >> -other-frame) which promise to display the location somewhere else than
> >> the current window.
> >
> > But AFAICS they only do that if there's a single candidate for the
> > definition, i.e. if the *xref* buffer is not displayed at all. Which
> > confused the heck out of me the first time I tried "C-x 5 .", btw.
>
> They do it for the final destination, but not for buffers temporarily
> displayed when you press `n' or `p'. E.g.:
>
> Press `C-x 4 .', type log-edit-menu, pick an element, press RET - and
> you'll see its location displayed in the "other" window. Same with `C-x
> 5 .', though to see the expected effect the destination buffer must not
> be already displayed in the current frame.
With RET, yes. But this doesn't happen with '.'. Isn't that
confusing?
> But if we're not allowed to hide *xref* on RET either, xref-goto-xref
> and xref-show-location-at-point's behavior should be close to this, and
> only differ in which window ends up being selected.
RET runs xref-goto-xref, so whatever RET does, xref-goto-xref will do
the same, no? What am I missing?
As for xref-show-location-at-point, it doesn't bury the *xref* buffer
when I try it now, so it looks like it already avoids hiding *xref*.
I have a terrible feeling that I'm missing something important here.
> >> That seems to make the most sense, but it will obscure the original
> >> code. Maybe we'd want to consult it while picking the exact option
> >> among the suggested definitions?
> >
> > I don't think I understand you here. By "obscure the original code"
> > do you mean the code will be harder to read? Or do you mean something
> > else?
> >
> > And what do you mean by "consult" -- consult what?
>
> I only mean that the original buffer will be hidden, and the user won't
> be able to look at its contents while making the choice. Which might be
> considered bad, for the default behavior. Maybe not too terrible, though.
No, I don't think it's terrible. There's always
xref-pop-marker-stack, right?
> (When there's only one option, jumping to it in the current window seems
> best to me
I agree.
- Re: tags-loop-continue, (continued)
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/21
- Re: tags-loop-continue, Eli Zaretskii, 2016/01/21
- xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/23
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Eli Zaretskii, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame,
Eli Zaretskii <=
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: tags-loop-continue, Stefan Monnier, 2016/01/17
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/17
- Re: tags-loop-continue, Stefan Monnier, 2016/01/17
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/17
- Re: tags-loop-continue, Stefan Monnier, 2016/01/17
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/17
- Re: tags-loop-continue, Eli Zaretskii, 2016/01/18