Re: xref and displaying locations in appropriate window or frame

[martin rudalics <rudalics@gmx.at>]

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