[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xref and displaying locations in appropriate window or frame

From: Dmitry Gutov
Subject: Re: xref and displaying locations in appropriate window or frame
Date: Tue, 26 Jan 2016 01:39:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]