GNU bug report logs -
#33870
27.0.50; xref-goto-xref not configurable
Previous Next
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):
>> 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.