Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/25/2016 09:18 PM, martin rudalics wrote:

> This is no good layout for IDEs.  Source/code windows like O and T
> should always form a rectangle.  Auxiliary windows like X should be
> arranged around that rectangle.

IDE-like window layout is not one of my goals here. I think I've 
explained how it would be less than idea.

That's not to say that the users shouldn't be able to choose this window 
management strategy (using display-buffer-alist?), but let's not bake 
this choice into xref.

>  > But I can live with O being split instead.
>
> This would nullify the above benefit.  In any case the larger of the two
> windows will be split.

It might be handy to split the window that shows the shortest buffer, if 
all other parameters are equal. But that's tangential to this discussion.

>  > Note, however, that from the X-below-O configuration I quoted above
>  > you can't each either of the good target configurations.
>
> You could split the parent window of O and X.

Very well (they have a parent window?). But that seems to imply manual 
layout management, instead of using e.g. pop-to-buffer.

> When X has short lines it could be shown on the left of O like this.
>
>   -----------------
> |X|   O   |   T   |
> | |       |       |
> | |       |       |
> | |       |       |
> | |       |       |
>   -----------------

Let's say that the lines in X are about half of the frame's width. At 
least, that's my usual experience.

>  >> Do you produce *xref* asynchronously?
>  >
>  > Not yet, we I hope we manage to do that. Only working synchronously is
>  > one of its drawbacks compared to Grep.
>
> Then ‘fit-window-to-buffer’ will be moot anyway.

Yes, sorry. It could still be useful in the alternative presentation 
method for xref-find-definitions, to be written by somebody, sometimes 
later.

>  > We'd split one of the windows again and show the target buffer in the
>  > new window. See my diagram at the beginning of this email.
>
> Then we're back at the initial problem that by default Emacs never shows
> more than two windows on a frame :-(

I suppose so. But its resolution should be orthogonal to what I do.

>  >> One problem with dedicated windows is that if an application and the
>  >> user both start dedicating the same window to its buffer there might be
>  >> conflicts.  I doubt that such conflicts can be "fixed" easily.
>  >
>  > So, then problem will occur when I un-dedicate it at the end, in
>  > unwind-protect? I suppose I can save its dedication status, and then
>  > restore it.
>
> Right.  I doubt you can do any better.  But do it.

Thanks!

>  > Indeed. Anyway, I'd be fine with changing the default, as long as
>  > side-by-side splits are still preferred.
>
> It always depends on the size and shape of your frame.

Ok, always preferred on my machine (229x58), then. :)

You might want to initiate a separate discussion about that. I'm not the 
person to make this choice, and nobody else is responding, this deep 
into this thread.

>  > All right, *Compilation*, then?
>
> IIRC the original question was where *Grep* and *Compilation* display
> their targets.  Here I practically always create a new window.  But by
> default the target will be usually displayed in the original window, the
> one selected at the time you called grep or compile.

The question was about the user being able to bury *Grep*, then switch 
back to it, and continue using it without issue. But indeed, *Grep* and 
*Compilation* have it easier.

>  > IMHO, the users won't bother, and will either switch to that buffer
>  > manually, or just repeat the search.
>
> So let's not prevent them from doing that ;-)

All right.