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

[martin rudalics <rudalics@gmx.at>]

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