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

[João Távora]

Juri Linkov <juri@linkov.net> writes:

>>> It's only a "problem" in your opinion :-)  I was assuming Eli also thinks 
>>> it's
>>> a bad default, but he hasn't confirmed this yet (and like Dmitry perhaps
>>> we was misunderstanding the reason for the behaviour). And neither has he
>>> said that your proposal is better.
>>
>> I thought I did express my opinions, but maybe I'm confused wrt the
>> question(s) you are asking.  Care to repeat them, for my benefit?
>
> 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.
n, for example, doesn't always split the window, only when it needs to
create a new window.  And the "new frame" exception is an _obscure bug_,
and even then it's one that your patch and my patch already solve, so
it's a completely moot point.

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.  Then we can all
try it for a while.  _Why_ is this so hard?

João