Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

>>   ------------
>> |     O      |
>> |            |
>> |------------|
>> |     X      |
>>   ------------
>
> That's not so fine: I'd prefer to go to
>
>    ------------
>   |  O  |   X  |
>   |     |      |
>   |     |      |
>   |     |      |
>    ------------
>
> at this step instead. Which is how Emacs normally allocates windows.
>
> Note the benefit: as long as the contents of O fit in its width (no 
exceedingly-long lines), we get to see more of its contents.
>
> Ideally, on the next step we get a layout like this:
>
>   ------------
> |   O |   X  |
> |     |------|
> |     |      |
> |     |   T  |
>   ------------

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.  And obviously it precludes fitting
*xref* to its buffer width.  A window fit to its buffer should never
impose its width/height on other windows.

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

> Having X in the split below O might be even better (giving T a
> full-height window), but I don't see a easy way to that configuration.

Neither do I.

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

>> to
>>
>>   ------------
>> |  O  |   T  |
>> |     |      |
>> |------------|
>> |     X      |
>>   ------------
>
> This would be a waste of space on the right side of X.

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

 -----------------
|X|   O   |   T   |
| |       |       |
| |       |       |
| |       |       |
| |       |       |
 -----------------

>> IIUC these buffers get filled asynchronously.  How should
>> ‘temp-buffer-resize-mode’ work with such buffers?
>
> Resize after every bit of output? Admittedly, it can be annoying.

Very.

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

> 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 :-(

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

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

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

> (I'm not too enamored with your description of Grep solution--too many
> steps--but that's beside the point.)

I prefer the first step rather than being overwhelmed by too many hits
with too much information.  And the second step is the same I use for
plain searching in buffers.

> Yes. Like I said, when I switch to it manually and press `q', it just
> buries the Help buffer. Is there a particular problem scenario you
> have in mind?

No.  I'm always glad if it works as intended.

> 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 ;-)

martin