[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: Sun, 24 Jan 2016 22:01:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

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

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

reply via email to

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