[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: Juri Linkov
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Wed, 09 Jan 2019 02:20:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> Of course, it doesn't work if you tried it only with part of my changes.
>> When I submitted my initial patch, I tested it in all your test cases,
>> including the above test case that was not broken with my patch.
> You are correct.  I was testing under the assumption that making
> xref-goto-xref configurable didn't require the "tiny window" for
> xref-find-definitions, which is something you stated that you wanted to
> do for other xref.el commands like xref-find-references.

Actually the xref window is not tiny at all if there are more results.
It doesn't takes more space than needed, therefore there is no wasted space.

>> My initial patch solved this problem gracefully by creating a new window
>> for the xref buffer.
> You may well call this a problem, but it's not a bug.  It's the defined
> behaviour, it's like this by design.  We are trying to create the
> conditions that would enable you, or any other user, to create
> alternative ways to present *xref* that have other advantages and
> drawbacks.

Let me reiterate the problem that prompted this report: please imagine
a situation that you have two horizontally split windows with visited files
in each of them, and you happily browse xref definitions in the same window
using M-.

Then suddenly M-. replaces other half of the screen with empty space with
only 2 lines at the top.  This is because there is an ambiguity in finding
definitions, and you need to resolve it.  Then you start trying to reuse some
empty space it creates and trying to split the xref window.  Instead of
this, the split is applied to the original window.  As a result, you have
the original window split, and still half of the screen wasted with empty
space.  And most of all this mess is caused unexpectedly, i.e. you don't
expect the xref window to break your windows when you type M-.

Do you agree that we should respect user configuration, and use
another window only when the user asks for it?  If yes, then a good way
to resolve this problem is to use a part of the original window to display
ambiguous results.  This will keep the original window configuration.

Now the question is what to do when the user asks to display
a definition in another window using ‘C-x 4 .’
(xref-find-definitions-other-window).  The most natural way is to
immediately take the window pointed out by the user configuration
(the user can configure to display it below/above/left/right etc.)
and display the xref window in that window.  Then visiting a definition
still will remain in the same window preferred by the user.

The same logic could also apply to xref-find-definitions-other-frame.

This will allow xref-goto-xref to be configurable.

reply via email to

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