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

[martin rudalics]

>> So before making this function public, we should resolve this calling
>> convention.
>
> Makes sense.  Then, in my view, the logical sequence to fix this bug is
>
> A. First do these changes to window.el and publish a decent
>     window-display-buffer calling convention.
>
> B. Push a xref.el based on the new function that doesn't change
> the xref UI.
>
> C. Discuss the xref.el UI in the other bug.

I can only comment on A and even there I have to leave the judgment to
Stefan Monnier as he's our only expert on window dedication and how
'display-buffer' is supposed to handle it.

But I can offer a preambulatory piece of code we could splice into the
function in order to do away with the DEDICATED argument.  Untested!

    ...
    (unless (eq buffer (window-buffer window))
      (set-window-dedicated-p window nil)
      (set-window-buffer window buffer))
    (let ((alist-dedicated (assq 'dedicated alist)))
      (cond
       (alist-dedicated
        (set-window-dedicated-p window (cdr alist-dedicated)))
       ((and (not (eq type 'reuse)) display-buffer-mark-dedicated)
        (set-window-dedicated-p window display-buffer-mark-dedicated))))
    (when (memq type '(window frame))
      (set-window-prev-buffers window nil))
    ...

> Do both of these more ambitious refactorings really need to
> make it in before we can do B as outlined above? Or can we
> do them later in parallel?

I recommend to do these before making that function public.  I don't
understand B and C sufficiently.

martin