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

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

On Fri, Feb 1, 2019, 07:30 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Fri, 1 Feb 2019 04:39:09 +0300
> > Cc: 33870@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).

[-- Attachment #2: Type: text/html, Size: 3207 bytes --]