[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Tue, 08 Jan 2019 15:47:07 +0100

>> 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)))
        (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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]