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 #383 received at 33870 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33870 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Fri, 1 Feb 2019 08:19:40 +0000
[Message part 1 (text/plain, inline)]
On Fri, Feb 1, 2019, 07:30 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Dmitry Gutov <dgutov <at> yandex.ru>
> > Date: Fri, 1 Feb 2019 04:39:09 +0300
> > Cc: 33870 <at> debbugs.gnu.org
> >
> > On 01.02.2019 03:17, João Távora wrote:
> > > emacs -Q
> > > C-x 2
> > > C-x o
> > > C-x 4 . xref-backend-definitions RET
> > > n
> > >
> > > <...> in
> > > your version, it works quite correctly.
> >
> > When I try this with the new patch, it results in a third window being
> > created (the original window is being split, and the definition is shown
> > there).
> > Is this the behavior we want?
> No, I don't think so.
>

It might not be the behavior you want, but it was the behavior I designed
it to have.

You start with two windows, A and B. You ask to find definitions in another
window from A, because you want to preserve its contents. The symbol you
searched for happened to have multiple definitions so you decide to browse
them from *xref* using bare 'n' and 'p' before settling on the definition
you want. Those "prospects" can't be shown in A because that would break
the original "other-window" contract/intention, and they can't be shown in
B because that's where you're browsing from. They need a new window C which
is not available. When the frame is relatively small (as it is with emacs
-Q), C is created by splitting horizontally, which is kind of akward, but
the decision where to create C changes with larger frames.

For some reason, 26.1 sometimes decides to make another frame for C, but
only if you start from B, i.e you add onde 'C-x o' to the beginning of the
recipe, after splitting. This is a bug in the current xref.el or, more
likely, in window.el's window-splitting heuristics. The bug goes away when
you have larger frames, which explains why I didn't catch it earlier.

Fortunately, the whole point of this bug report opened by Juri is to make
this configurable. Later, we can decide on a better default, something Juri
is also very much in favor of. If you add your voice to his and decide to
change the default, and then give me a way to recover 26.1's behavior
(minus the bug), I won't object (much).
[Message part 2 (text/html, inline)]

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.