bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost )

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/23/17 11:03 PM, João Távora wrote:

> I read the discussion you pointed me to me by Dmitry in
> http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01235.html.
> 
> Eli, If I understand your concerns there, then the first and third
> patches I proposed shouldn't in any way interfere with your use of
> *xref*-related facilities.  If anything, they should improve it.

Overall, I don't have strong objections, so if Eli is fine with the new 
behavior all around, I don't mind getting them in (with maybe a few 
modifications), and hopefully we'll reach some better solutions by the 
next release.

For some more context though: previously, I've tried to make it seem 
"like xref buffer was never there" after the user performed the 
navigation, in other respects too:

- As we recall, the xref buffer was buried after the user performed the 
navigation.

- The window configuration was fully restored to the one before the xref 
buffer was shown (with some checks like making sure the user didn't 
change the configuration manually thereafter), and then the navigation 
was performed. After that, using the "originally intended" window or 
frame was much easier.

- All buffers that were opened just to show the xref locations were 
cleaned up (closed) after the navigation was performed.

...But in the end, all this stuff worked not reliably/fast/intuitively 
enough, and I came to the conclusion that it's not a good choice when we 
have an *xref* buffer that stays around for a long time. So it was removed.

Now to your patches.

> * 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch
> 
> This extends the exception granted by split-window-sensibly to
> single-window frames whose dimensions are below those of splitting
> thresholds to consider multi-window frames where all but one window is
> dedicated.

If there are other non-dedicated windows, will one of them be used (that 
would seem fine)?

> In practice, it fixes the case where
> 
>    C-x 4 . xref-backend-definitions RET n
> 
> would surprisingly pop-up a new frame if the original frame was already
> small to start with.
> 
> This fix to window.el appears very sound to me, but if it is not desired
> for whatever reason, a more localized fix in xref.el is also possible.

A fix in xref.el sounds more prudent to me, but someone else would have 
to comment on window.el.

> * 0004-Don-t-quit-xref-window-on-RET-only-on-C-u-RET.patch
> 
> This fixes the "disappearing *xref* problem", by bringing back the
> default behaviour of not quitting the *xref* window on RET, although
> allowing for that if the user types C-u RET instead.

I have to wonder if we have other commands that quit the current window 
when called with a prefix. Particularly commands bound to RET.