Re: xref and displaying locations in appropriate window or frame

[martin rudalics]

> First, I'd like to point out that your suggestion was to split the
> current window and display X in the bottom part of the split. Which,
> if there were, say, two side-by-side windows originally, wouldn't put
> X in any of "classical" areas designated for "view" windows by IDEs.

My suggestion was and is to display X at the bottom of the frame via
‘display-buffer-at-bottom’ like *Completions*.  So if there were, say,
two side-by-side windows originally, this would put X in a "classical"
area designated for "view" windows by IDEs.

> But suppose I misunderstood, and the end result would be putting X
> into a lower part of the frame, below all file windows. Which fits an
> average IDE fine, because they don't have side-by-side splits for file
> windows (let's keep to Emacs terminology here),

What makes you think that average IDEs don't have side-by-side splits
for file windows?  ECB has them IIRC.

> so one can at least
> expect that a average line of code is more or less as long as the
> frame width. Maybe less, but probably longer that width/2.
>
> Thus, a file search output will be just as wide, and one can't really
> do better that display it in a full-width window as well at the
> bottom. I'd say that would show too few lines, when my font of choice
> is used, but the IDEs seem to handle it fine somehow with their
> defaults.

Yes.  Do you see any problems with that?

> That's not necessarily untrue in Emacs community, where we're often
> more conservative, and hold to 80-100 chars per line. Then, we can
> afford to put file windows side-by-side,

... assuming your 229 columns wide frame, I suppose ...

> and xref output (though not
> Grep, because it includes a file name on each line) is about the same
> width, so by putting it at the bottom we'll waste the right half of
> the "view windows area".

Yes.  We're back at my inital proposal to give *xref* buffers a
multicolumn layout.

> But I don't really have a better layout in mind, and different
> long-time users probably solve this question differently. So, really,
> the best I can do is use as much from the default window allocation
> strategy as I can, and hope that users with more exotic demands manage
> to override the given behavior to their satisfaction.

Let's see.

martin