[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xref and displaying locations in appropriate window or frame

From: Dmitry Gutov
Subject: Re: xref and displaying locations in appropriate window or frame
Date: Sun, 24 Jan 2016 20:08:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/24/2016 05:38 PM, martin rudalics wrote:

Ignore ‘standard-output’.  The only important thing to know is that
‘with-temp-buffer-window’ initially erases the buffer it displays, so
you have to ‘insert’ within BODY and never before.

That doesn't seem to be true. Try:

(with-temp-buffer-window "test" t nil
  (insert "abc"))

It shows the buffer "test" empty, and "abc" gets inserted into the buffer that was current before with-temp-buffer-window call.

Currently the *xref* window occupies one half of my screen and usually
wastes lots of screen space.  So making it smaller should give users
more space for the buffers they eventually want to show.

Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to the problem I currently have.

I thought it's forest-like.  If it's really tree-like then rotating it
will be probably hard :-(

Anyway, IME most lines in xref take more than half of its width (which is ~110 here). So rearranging them wouldn't help much.

 > What if the original window is already at the bottom of the frame?
 > And, say, isn't tall enough to split?

Then *xref* will reuse the window on the top that cannot be resized and
we lose.  I wonder whether this happens often with the *Completions*
window though.

The current issue is that people want *xref* to behave less like *Completions* (transient, disappearing soon) and more like *Compilation*, which stays until the user explicitly buries it or kills it or its window.

That may be not ideal for xref-find-definitions, but it seems more appropriate for all other commands using the xref UI.

With a wide window, ‘split-window-sensibly’ will probably try to split
that window into two side-by-side windows based on the assumption that
it didn't do so before when displaying *xref* (that's why I would try to
display *xref* on the bottom).  As for the "not reusing the original
window part" this will happen only if the original window is not the
larger one.  So you would have to temporarily select the original window
in the ‘xref-find-definitions-other-window’ call.  Not nice, but I see
no better choice.  You could also temporarily dedicate the original
window to its buffer.  Not nice either.

I think I need to "not reuse the original window", nor xref's window. And reusing the original window is more preferable than reusing the xref's window.

Can I make xref's window temporarily dedicated, and call pop-to-buffer from the original window?

How would we do that?  We have already two vertically stacked windows -
the original one and the *xref* window.  As a rule, ‘display-buffer’
refuses to make a third window.  The default of ‘split-height-threshold’
is 80 and we usually start with a total root window height of 34.

So if the frame is too narrow, and there are two windows only, the location will be displayed in the original window? OK, that should be fine.

I asked a couple of times whether this makes any sense but nobody cared.

What makes sense? Having a split threshold? I think it does. Beyond that, I'd say window management might be too complex for a casual commenter to say whether it makes sense or not.

Now obviously you can use ‘display-buffer-overriding-action’.  But the
idea of ‘display-buffer’ based functions is to give users the necessary
means to tweak the behavior to their working environment (display size,
frame/window preferences, maximized/normal-sized frames, etc.).  So you
want to have a good reason for overriding the user.

Right. I really want to use the standard behavior as much as possible.

 > Yes, displaying the buffers in the original window is not hard, we
 > just have to save a reference to it (although it'd be bad if the user
 > switches to *xref* in that window manually).

Why would she want to do that if you keep *xref* visible as long as it's
needed?  If the *xref* window is gone, the user should never switch to
*xref* manually but ask you to redisplay it.

They can press `q', but then switch back to it a while later. I see no reason to prohibit this.

Do we prohibit things like that in some other buffers?

Note: Everything I wrote here is based on your initial assumption to
keep *xref* visible all the time.  If you don't do that, the three
windows rule doesn't apply and you shouldn't have any of the problems I

That is indeed the whole reason I've written the "I'm stumped" email.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]