Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/25/2016 12:50 PM, martin rudalics wrote:

> If the *xref* buffer usually fills its window in both dimensions there's
> no need to do anything.

Usually or not, depends on which commands you use, and what you search 
for. Probably not most of the time.

>   -----
> |  O  |
> |-----|
> |  T  |
> |-----|
> |  X  |
>   -----
>
> and subsequently T should be reused for the remaining targets.  This
> will work when the user has customized ‘split-height-threshold’
> appropriately - otherwise O will be used for showing T.

That's fine.

> In a "horizontally" orientd frame you would go from
>
>   ------------
> |     O      |
> |            |
> |            |
> |            |
>   ------------
>
> via
>
>   ------------
> |     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  |
 ------------

But I can live with O being split instead.

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.

Note, however, that from the X-below-O configuration I quoted above you 
can't each either of the good target configurations.

> to
>
>   ------------
> |  O  |   T  |
> |     |      |
> |------------|
> |     X      |
>   ------------

This would be a waste of space on the right side of X.

> Now suppose that both O and N exist.  In this case you would, in the
> vertically oriented case, go from
>
>   -----
> |  O  |
> |     |
> |-----|
> |  N  |
> |     |
>   -----
>
> via
>
>   -----
> |  O  |
> |-----|
> |  N  |
> |-----|
> |  X  |
>   -----
>
> to
>
>   -----
> |  O  |
> |-----|
> |  T  |
> |-----|
> |  X  |
>   -----

This is also fine.

> The second tricky case is to make sure that for a new target always the
> previous T window gets used via ‘display-buffer-use-some-window’.  To
> make this happen you will either have to mark the O and X windows as
> dedicated or make sure the T window is the LRU window when displaying
> the next target.  (I silently assumed that N will be automatically used
> for displaying T initially because O was selected and X would have to be
> selected by you when it's created.)

Dedicated it is, then.

>  > Maybe the actual solution is indeed to use a different display
>  > mechanism for xref-find-definitions with several options. Then it
>  > could use an actual temporary electric window at the bottom of the
>  > current window that gets deleted as soon as we're done.
>
> At least that's how I would customize the display of *xref*.  Whatever
> you choose for the default might be entirely different based on the
> needs of a majority of users.

Unless someone would like to send a patch, I'll hold off on implementing 
this, because we've not really stabilized on anything, including the 
calling convention of xref-show-xrefs-function.

And the above feature would be closely related to that variable.

>  > We don't use temp-buffer-resize-mode in Compilation or Grep buffers,
>  > right? Even though Grep likewise might return only a few matches.
>
> 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.

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

>  > Were the Help windows actually _temporary_ sometime?
>
> Depends on the semantics of "temporary".

I'd only call that a window that usually disappears before the next 
command. But that's just me.

>  > If I have a frame with two full-height windows side-by-side, and I'm
>  > calling project-find-regexp which returns a lot of results, I'd want
>  > it to be displayed in the "other" window, rather than necessarily
>  > split the current one.
>
> I thought the other window is where you eventually wanted to show the
> target buffer.

I don't think that when the user calls any other-window command, they 
have a specific window in mind (for that, they'd have to know the window 
numbering somehow). IMHO, -other-window just means "some other window in 
the current frame".

>  > Or, if I have just one window in a maximized frame, and do the search,
>  > and I've customized the split thresholds appropriately, I want
>  > split-window-right to be called, and see *xref* to the right.
>
> Once more: Where would you show the target buffer then?

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.

>  > Instead of having the "split below" performed, and seeing *xref* use
>  > full width, and only half the height of the current frame.
>
> Hopefully less than half the height when you fit the window to its
> buffer.

Like mentioned, xref's contents can be long (even if they usually 
aren't, in xref-find-definitions output).

>  >> Yes.  But the one-window-per-frame user might get a new frame then.
>  >> She's not your target (because of the assumption that the original
>  >> window and the *xref* window are already there when you want to display
>  >> the other buffer).
>  >
>  > Wouldn't she want a new frame anyway?
>
> I thought about people who work with one and only one window.  We
> shouldn't create a no-way-out situation for them.

I'm accepting suggestions on what to do in this case. We should handle 
the more common ones first, however.

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

>  > Maybe it does make sense, maybe it doesn't. I'm fine with it, though,
>  > because I don't mind doing doing my vertical splits manually.
>
> ‘display-buffer’ can't split it.  The very first example above will work
> only if the user has customized ‘split-height-threshold’.  Otherwise, T
> will be shown in the O window.

Indeed. Anyway, I'd be fine with changing the default, as long as 
side-by-side splits are still preferred.

>  > But *Grep* works fine in that situation, doesn't it?
>
> I never use it.  My grep hits appear in a side window where I just list
> the files where at least one hit occurred.  Selecting a file shows all
> hits in that file.  Selecting a particular hit shows that hit in the
> window on the right.

All right, *Compilation*, then?

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

>  > quit-window is different, and it works as expected anyway, I'd say: if
>  > the window configuration hasn't changed too much, it will undo the
>  > action that displayed it. If the window configuration did change too
>  > much, it will just bury the current buffer. Everybody happy.
>
> Did you try it after manually switching to such a buffer?

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?

>  > I can easily imagine having several *xref* buffers at the same time
>  > (we'll just have to add more coherent naming).
>
> Then I'd say: Maybe some prefixed command to "bring back" an existing
> *xref* buffer would be more useful than simply switching to it.

IMHO, the users won't bother, and will either switch to that buffer 
manually, or just repeat the search.