Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

> With its standard-output binding, with-temp-buffer-window is a kind of
> weird beast. Why would I prefer to use the low-level printing
> primitives, instead of `insert'?

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.

> Otherwise, I'd be happy to make temp-buffer-resize-mode work. But
> anyway, it seems orthogonal to my question: after *xref* is displayed
> already, how do I show locations from it?

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.

>  > By default *xref* would be shown at
>  > the bottom of the frame with columns arranged as in the *Completions*
>  > buffer.
>
> xref's output is tree-like. It seems hard to arrange it in multiple columns.

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

> 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.

>> Conceptually, this should allow to split the "original" window into two
>> side-by-side windows where the left one would continue to display the
>> original buffer and the right one would display the buffer chosen by
>> ‘xref-find-definitions-other-window’.  If there's already another window
>> on the side of the original window, that window would be reused by
>> ‘xref-find-definitions-other-window’.
>
> How will this happen?

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.

>> Obviously, if the frame is too narrow, splitting will fail and the
>> buffer will be shown in the original window.  But, as mentioned above,
>> there's nothing you can do about this.  The doc-string of
>> ‘xref-find-definitions-other-window’ should probably mention it.
>
> I imagine then the user might expect it to be shown above or below the
> original window. Won't they?

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.  I
asked a couple of times whether this makes any sense but nobody cared.

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.

> 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.

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
cited.

martin