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

[Juri Linkov]

>> I propose to remove this function and replace its parts with
>> more alists, i.e. this blob
>>
>>                               `(,(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))))
>>
>> with something shorter like `(fit-to-buffer . t)'
>
> Can't we add this via a special value for the 'window-height' alist
> entry?  Where we explicitly state that it obeys
> 'temp-buffer-resize-mode' if that is active and the buffer qualifies
> as temporary and so on ...  Or is that what you mean already?

I meant to make it shorter in any possible way, so using something like
'(window-height . resize)' seems to achieve this goal.

>> And also to replace a long list of display-buffer-* that is a copy of
>> `display-buffer-fallback-action' with something shorter like an alist
>> `(pre-action . display-buffer-fallback-action).
>
> I'm not sure I understand you.  'display-buffer-fallback-action' is
> always tried after everything else failed.  Would you want to run it
> _before_ something else?

Exactly.  There is a long list of actions in display-buffer--maybe-at-bottom
before calling the main action 'display-buffer-at-bottom', so it makes sense
to move them somewhere to a common place.

>>> A single window frame where the buffer is not displayed runs this
>>> part.
>>
>> You are lucky if you can invoke its second branch.  I always get only
>> its third branch in all tried configurations when testing with
>> completions of `C-x C-f TAB TAB'.
>
> I now always display completions in a child frame so I never run into
> practical problems with it.

Then what problems are possible with binding 'split-width-threshold'
or 'split-height-threshold' to nil?

>> After resizing an initial frame to 12 lines, so every vertically split
>> window gets 6 lines, typing `C-x C-f TAB TAB' displays *Completions* in
>> the upper window, when a previous window where *Completions* was
>> previously displayed was moved to the upper window, e.g.
>>
>> 0. emacs -Q
>> 1. resize the frame to 12 lines
>> 2. C-x 2
>> 3. C-x C-f TAB TAB C-g   ;; *Completions* were displayed in the bottom window
>> 4. C-x 0
>> 5. C-x 2
>> 6. C-x C-f TAB TAB C-g  ;; *Completions* displayed in the upper window that 
>> was previous
>
> Your bag of tricks is fathomless :-)  Basically, this means that
> 'display-buffer-in-previous-window' and 'display-buffer-at-bottom' are
> inherently irreconcilable when a window was at bottom once and moved
> upwards.  We could abuse the existing 'side' action alist entry for
> not-atomic, non-side windows in the following sense: If 'side' equals
> 'bottom', a window is eligible for reuse if and only if it appears on
> that side of the frame.  To be obeyed by 'display-buffer-reuse-window'
> and 'display-buffer-in-previous-window', I presume.  WDYT?

This makes sense.  Even more, maybe it would be possible to use only
an alist '(side . bottom)' instead of specyfying the action
'display-buffer--maybe-at-bottom'?