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

[Juri Linkov]

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

C-x 5 . pops up the *xref* buffer in an adjacent window
RET     visits references in a new frame
TAB     visits references in a new frame
n       visits references in a new frame

Problems: the case of 'C-x 4 .' is a mess.  Other cases are consistent,
but take screen space from an adjacent window.  The proposed behavior
solves all these problems:

* Proposed new behavior

M-.     pops up the *xref* buffer in a tiny window below the original 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 a tiny window below the original window
RET     visits references in a new window
TAB     visits references in a new window
n       visits references in a new window

C-x 5 . pops up the *xref* buffer in a tiny window below the original window
RET     visits references in a new frame
TAB     visits references in a new frame
n       visits references in a new frame

However, the problem is that I don't understand the complicated logic
of the 'C-x 4 .' case of the old behavior, so I can't completely
support all its intricacies after code simplification.