GNU bug report logs - #33870
27.0.50; xref-goto-xref not configurable

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 25 Dec 2018 20:53:01 UTC

Severity: minor

Found in version 27.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #173 received at 33870 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: João Távora <joaotavora <at> gmail.com>
Cc: 33870 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Gutov <dgutov <at> yandex.ru>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: 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)))
      (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




This bug report was last modified 6 years and 35 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.