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

[Juri Linkov <juri@linkov.net>]

>> 1. simplifies ‘xref--show-pos-in-buf’
>
> ... and considerably complexifies xref--show-xref-buffer (more on that
> later)
>
>> while at the same time preserves the current behavior and respects
>> user's customization of display actions;
>
> That's great!

I realized now that it can be simplified more by replacing

(with-selected-window (display-buffer buf action)

with just

(pop-to-buffer buf action)

but I'm not sure about this change because it could change the current behavior.

>> 2. makes the xref buffer non-obtrusive like *Completions*
>>    in xref--show-xref-buffer;
>
> After a brief look, I'm not sure I like the UI change.  "not sure" is
> not an euphemism for "don't like", I'm ust not sold on the idea yet:
>
> * Certainly you don't mean non-obtrusive, you mean "less obtrusive" and
>   really it's "slightly less obtrusive".  It does use potentially less
>   space and doesn't temporarily use one of your windows if you happen to
>   have several.  I agree this is an good advantage.
>
> * But by using less space it is also less useful.  You don't get to see,
>   at a glance, a great deal of xrefs.  And xrefs are different from
>   completions, they're closer to grep hits.  You wouldn't put *grep*
>   hits in such a potentially tiny window, would you?
>
> Then again, perhaps you would, and the whole point of this patch is to
> make the UI configurable.  If so, I'd make the original UI the default,
> or at least very very easy to bring back.

I see what you mean.  For a command like project-find-regexp I'd like
the original UI as well, because most of the time there are many hits
displayed in the xref window.  But when xref-find-definitions pops up
the xref window, usually it contains just 2 lines taking half of the screen
where most space is uselessly empty.

So it seems that project-find-regexp and most other xref-related
commands are more like grep while xref-find-definitions is more like
completions with a small number of lines.

What do you think about allowing only xref-find-definitions
to display a narrow xref window below the original window?

>> -          (display-buffer buf action))
>> +                 `(,(lambda (buf alist)
>> +                      (window--display-buffer buf xref--original-window 'reuse alist)))))))
>>
>
> Using internal "--" symbols from window.el is a temporary solution I
> hope.

Actually this function is not quite internal.  It's intended to be used
in display actions implemented by packages.

>> -        (pop-to-buffer (current-buffer))
>> +        (pop-to-buffer
>> +         (current-buffer)
>> +         `((display-buffer--maybe-same-window
>> +            display-buffer-reuse-window
>> +            display-buffer--maybe-pop-up-frame
>> +            display-buffer-below-selected)
>> +	   ,(if temp-buffer-resize-mode
>> +		'(window-height . resize-temp-buffer-window)
>> +	      '(window-height . fit-window-to-buffer))
>> +	   ,(when temp-buffer-resize-mode
>> +	      '(preserve-size . (nil . t)))))
>
>
> Again, too many --, and seems like a lot of repetition from window.el.

The distinction between internal and public window functions is quite fuzzy.

> Perhaps you want window.el to export a function that encapsulates
> all/some of this cruft to pass as ACTION.

Yes, creating a composite display action would be a good thing to do.

> Naming that function would be the hardest problem (best I could do is
> display-buffer-use-completions-like-window).

Or when naming by not its usage but what it does: display-buffer-below-and-resize.

> Or maybe put that function in xref.el.  But as I said above, I think we
> also need a function that brings back the current default.

I propose to use the new function only for xref-find-definitions.