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

[João Távora]

Juri Linkov <juri@linkov.net> writes:

> I don't understand what does this "keep original window intent" mean.
> Please explain.

Hi Juri.

You can read up the whole bug here:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28814

I quote from that thread:

    Here are two very simple Emacs -Q recipes that demonstrate [the bug]
     
       emacs -Q
       C-x 3 [split-window-right]
       C-x 2 [split-window-below]
       M-. xref-backend-definitions RET [xref-find-definitions]
       C-n [next-line]
       RET [xref-goto-xref]
     
    Expected the definition to be found in the original window where I
    pressed M-. but instead it was found in another. Another case:
     
       emacs -Q
       C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-window]
       C-n
       RET
     
    Expected the definition to be found in some other window, different
    from the one I pressed M-. on. Instead went to the same one. Also,
    in both situations, expected the window configuration to be the same
    as if I had searched for, say, xref-backend-functions [which only
    has a single definition].

The bugfix makes these two recipes work like expected (that is the
"Expected the definition" sentence is now fulfilled).  We want to make
sure this is not broken.

> I want to understand how it is different from other modes that display
> a buffer in another window, such as e.g.  after `C-x C-b'
> (list-buffers) typing `C-o' displays the buffer in another window, or
> e.g. typing `C-o' in the Dired buffer opens it in another window, and
> many other cases.

*Before* pressing C-x C-b, you probably had no expectations as to what
window should be used to display your decision.  But M-. you have:
M-. means "use the same window", C-x 4 . means use "other window" and
C-x 5 . means "other frame".  Crucially, the existance or not of
multiple loci of the (something that generally cannot be known in
advange) shouldn't influence the results of "other window" or "other
frame" intention.

So, by default, if display-* variables not are set specially by the
user, then final product of those two recipes should stay the same and,
more importantly, the principle that I described in the previous
paragraph should hold.

>> However here's a tangent that might affect the decision.
>> Is there any impediment to making xref.el a core ELPA
>> package? I can see some advantages... The reason I bring
>> this up here is that using very new elisp in a file can reduce
>> the usefulness of that goal, which in this case would be
>> to bring new xref features to users of Emacs 26.1/26.2.
>> Perhaps it is already using post-26 features in which case
>> the ship has sailed.  In that case, disregard this tangent.
>
> Display actions have been in Emacs for a long time customizable
> by `display-buffer-alist', so if you need some specific logic,
> it's easy to implement the corresponding display action
> that can be overridden by the users.

I know that.  I think either I or you missed something in this
paragraph.  Let me put it like this: are you planning to use, in
master's xref.el a new Elisp feature (a new function, argument to a
function, or a new semantics of a specific argument) that would make
loading that file in Emacs 26.1 fail in some way or other?

If master's xref.el works in 26.1 before your changes, and not anymore
after your changes, then the possibility of putting xref.el in ELPA as a
"core" package is lost.  (But perhaps that possibility is not desirable
to begin with, so this is why I said this was a tangent).

João