Subject: Re: bug#33870: 27.0.50; xref-goto-xref not configurable

From: Juri Linkov <[email-masked]>
Date: Mon, 04 Feb 2019 23:35:46 +0200

>> Let me summarize my point of view of the current situation:
>>
>> * Old behavior:
>>
>> M-.     pops up the *xref* buffer in an adjacent window
>> RET     visits references in the original window
>> TAB     visits references in the original window
>> n       visits references in the original window
>>
>> C-x 4 . pops up the *xref* buffer in an adjacent window
>> RET     visits references in the same window where *xref* buffer was
>> TAB     depending on window configuration visits references either
>>         in the same window where *xref* buffer was or in the original window
>> n       splits the original window and visits references in a tiny window,
>>         sometimes opens a new frame
>
> Unfortunately, you're trying again to kick up a dust cloud around the
> matter.  You description is only partially true for the two-window case.

Yes, it's only partially true, I admitted this by saying that
I don't understand its complicated logic.

> Let's use your 100%-backward-compatible patch, (since it is the simpler
> of the two). For the millionth time: _after_ we get _some_ patch
> installed, I invite you to open a new customization option (or just a
> simple variable) that lets me toggle on and off between the current
> behaviour and the behaviour that you think is superior.

I don't think that the behaviour I proposed is superior.
In particular, my previous proposal behaves poorly
in combination with windowmove, e.g. typing
<S-M-up> M-. to display the reference in the upper window,
when there are ambiguities it displays the xref buffer
in the upper window, and then typing RET visits the reference
in a wrong window (in the original window).

I hoped to have more discussion to find the best solution.

> Then we can all try it for a while.  _Why_ is this so hard?

It's hard to support all details of old behavior in all possible interactions.