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

[Juri Linkov]

> I wouldn't say it's perfect either, it's still kind of idiosyncratic. Not
> sure your patch will fix that problem, though, instead of just swinging it
> the other way.
>
> We basically have two use cases:
>
> * Jump to this symbol, in this/that
> window/frame. windmove-display-in-direction should probably affect where
> the target buffer ends up, irrespective of whether we have to pop up an
> *xref* buffer to resolve any duplicate matches.
>
> * Show a list of search results. Arguably, in this case
> windmove-display-in-direction should affect where the *xref* buffer
> is displayed.
>
> Neither of y'all's patches solve this, I believe.

Why do you think this display action proposed in my previous patch can't solve 
this?

  `((display-buffer-in-previous-window)
    (previous-window . ,xref--original-window))

Then there is no need to use a new relative-window alist entry 'from-window'
in display-buffer-in-window because xref--original-window is absolute 
addressing.