Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/24/2016 09:12 PM, martin rudalics wrote:

> Because of "Do not make that buffer current for running the forms in
> BODY."  You have to use ‘with-current-buffer’ around the ‘insert’.

Could we decouple temp-buffer-resize-mode from the "write to 
standard-output" mode of operation? Can I just call 
resize-temp-buffer-window once after the xref buffer is displayed?

>  > Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to
>  > the problem I currently have.
>
> Not entirely.  I'd make the *xref* window as small as possible so it
> doesn't get split.

If won't make any difference if *xref* is tall enough (like when we 
display Grep results in it).

And anyway, *xref* window getting split is not a problem, as far as I'm 
concerned. Keeping *xref* buffer visible is the goal.

 > And I'd like to see it always at the same frame position.

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.

>  > Anyway, IME most lines in xref take more than half of its width (which
>  > is ~110 here). So rearranging them wouldn't help much.
>
> With a maximized frame I get 200 columns here.  Anyway.  Don't bother
> about laying out its contents.

I get ~230, but the first thing I do is a side-by-side split. :) While 
we can do space-saving layout in *Completions*, most buffers, like 
file-visiting ones, don't have that luxury anyway.

> But here usually the *xref* buffer never
> occupies its full _height_.

It might, if you call xref-find-references, or project-find-regexp, 
depending on what you're searching for.

>  > The current issue is that people want *xref* to behave less like
>  > *Completions* (transient, disappearing soon) and more like
>  > *Compilation*, which stays until the user explicitly buries it or
>  > kills it or its window.
>
> This should be of no importance.

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

> Help windows are also displayed via
> ‘with-temp-buffer-window’ and don't disappear soon.  Some people keep
> the help window open all the time.

Were the Help windows actually _temporary_ sometime?

> The IMHO important aspect is that
> *Completions* uses ‘display-buffer-at-bottom’ which calls plain
> ‘split-window’ and thus is not limited by ‘split-height-threshold’.  You
> can obviously use ‘display-buffer-at-bottom’ with plain ‘display-buffer’
> as well.  But then ‘temp-buffer-resize-mode’ won't get called.

I don't know if it's that important. Also consider this:

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.

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.

Instead of having the "split below" performed, and seeing *xref* use 
full width, and only half the height of the current frame.

>  > Can I make xref's window temporarily dedicated, and call pop-to-buffer
>  > from the original window?
>
> 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?

> But even softly (that's all you need here) dedicated
> windows sometimes behave erratically.

Can we fix that? So far using dedicated buffers sounds like the most 
appropriate solution.

>  > So if the frame is too narrow, and there are two windows only, the
>  > location will be displayed in the original window? OK, that should be
>  > fine.
>
> If the other window is the *xref* window and the *xref* window was
> "used" later.  You might have to "touch" it from time to time ;-)

That doesn't sound like something a display-buffer consumer should do. 
Should it?

> A threshold that is more than twice as large as the default value?

(frame-height) evaluates to 58 here.

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.

>  >> Why would she want to do that if you keep *xref* visible as long as
> it's
>  >> needed?  If the *xref* window is gone, the user should never switch to
>  >> *xref* manually but ask you to redisplay it.
>  >
>  > They can press `q', but then switch back to it a while later. I see no
>  > reason to prohibit this.
>
> Neither do I.  But in a sense this is a bit like an ediff user deleting
> the control panel and switching back to it later.  The ideal layout may
> have gone at that time.

But *Grep* works fine in that situation, doesn't it?

>  > Do we prohibit things like that in some other buffers?
>
> Not to my knowledge.  I just wouldn't call it good user practice.  For
> example, switching to *Help* in an arbitrary window and doing
> ‘quit-window’ there is not likely producing good results.  The same will
> hold for ‘q’ in a window where you manually switched to *xref*.

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.

> Maybe
> some command to "bring back" the *xref* buffer would be more useful than
> simply switching to it.

I can easily imagine having several *xref* buffers at the same time 
(we'll just have to add more coherent naming).