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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> OK, but is it the correct thing to do? The thresholds are there for a
> reason, and having a window that's only a few lines tall (which could
> happen in some example) will hardly be more helpful than showing it in
> a different window, even if the user expected xref to use the "other
> window".

Well, I don’t think it’s that bad if a tiny window pops up, considering:

1. The user *did* type C-x 4 . , meaning he specifically requested "a
different window", so that’s life. Tiny windows can pop up via the
existing exception in split-window-sensibly, too.

2. I assume we want to stand by Eli’s wish that the *xref* buffer should
stay visible (and anyway the user has a failsafe C-u RET command that
buries it and should improve the situation).

> This stuff is difficult, and personally I don't like either of the
> easily reachable solutions.

We’re talking about the edge cases here. Would you like a solution where
the user’s intention (1) is disregarded in extreme cases (and thus the
original window is considered even if the user did C-x 4 .)

>> I see and I will try to answer. I proposed two patches previously:
>>
>> * a first one to fix the non-determinism of window popping/selecting
>> behaviour;
>> * a second one to make the *xref* buffer less obstrusive.
>> * (now there is the third one that fixes the frame-popping glitch)
>>
>> IIUC it is the second one that clashes with "the dissapearing *xref*
>> problem" that I have yet to read up on. If we don't come up with a
>> solution for that, I would be OK with a solution that leaves it unsolved
>> but adds some customization point (hook) for the user to put this
>> behaviour in.
> 
>Indeed, but there's also a matter of consistency, and of making the
>overall design work in a predictable fashion. More in the follow-up
>email.

Any of the two alternatives are more predictable than what we have
now. A gain in predictability.

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

I see, there’s prior art here. You approach is much more ambitious than
mine and given the hairiness of window code, it’s no wonder it didn’t
work well, if you will excuse the hindsight 20/20 :-)

My approach is less ambitious but works well and predictably for these
(more than) common cases:

The case where I *do want* my current window (and only that one) to get
clobbered.

   M-. symbol-with-multiple-definitions RET
   n [0 or more times]
   p [0 or more times]
   RET [the final decision, or C-u RET to ditch the *xref* buffer]

And also the case where I *don’t want* my window to get clobbered, and
don’t care about the other ones.

   C-x 4 . symbol-with-multiple-definitions RET
   n [0 or more times]
   p [0 or more times]
   RET [the final decision, or C-u RET to ditch the *xref* buffer]

If it helps, this itch didn’t pop out of thin air: as you know, xref.el
is lifted from SLIME’s UI. SLY, my fork of SLIME, does the same, and a
user complained about SLY’s use of popup windows in a way that finally
convinced me. See https://github.com/joaotavora/sly/issues/121

>> * 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch

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

Yes, of course, in keeping with the current spirit that splitting a
small window is a last resort before popping a frame.

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

I see, it’s a bit odd indeed, but I had no idea of any kind of rule or
policy in that direction.

Anyway, In the thread you pointed me to, there was talk of an ’a’
command but I never saw it. It was some hypothetical
xref-quit-and-goto-xref. I’m perfectly fine with implementing that
instead.

Of course my priority goes towards RET doing xref-quit-and-goto-xref and
something else doing xref-goto-xref. If that default isn’t changed, I’ll
probably to that remap in my init file..




João