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.
>
> 'resize' is too short IMHO.  'resize-to-fit' maybe.

Good name.

>> 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.
>
> But running a "fallback" action before the others doesn't sound very
> intuitive.

Maybe some more suitable name for actions to add between
display-buffer-overriding-action and user-action?

>>> 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'?

Or '(direction . bottom) or shorter '(dir . bottom)
compatible with terminology of window-in-direction
because the word "side" is associated with side windows.

> We could use the six abbreviations we have ('left', 'top', 'above',
> 'right', 'bottom' and 'below') to make a window on the respective side
> either of the selected window or the frame.  Then we would need one
> action function say 'display-buffer-beside' and yet another action
> alist entry say 'beside' with the values 'selected' (on any side of
> the selected window), 'main' (on any side of the main window) and a
> window (on which side this would have to be created).

Maybe better 'frame' instead of 'main'?