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

[Juri Linkov <juri@linkov.net>]

>> The semantics is that they do what the default actions do
>> plus something specific.  Maybe then move the default part
>> from their body to some other fallback layer?  Then just use e.g.
>> display-buffer-at-bottom, without the -maybe part.
>> Or maybe use an alist for that, something like
>>
>>    ((maybe-try . default-actions))
>
> I would never have written these "maybe" function in the first place.
> They need more code lines then they spare.  So I have no real opinion.

I understand that the word “maybe” indicates it's not guaranteed that
the function will do what it's intended to do.  IOW, these functions
are conditional.

Since we can't lightly rename old functions, I have a question only
about functions added in Emacs 27, namely, display-buffer--maybe-at-bottom.
Its current body:

  (let ((alist (append alist `(,(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)))))))
    (or (display-buffer--maybe-same-window buffer alist)
        (display-buffer-reuse-window buffer alist)
        (display-buffer--maybe-pop-up-frame buffer alist)
        (display-buffer-in-previous-window buffer alist)
        (display-buffer-at-bottom buffer alist)))

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

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).

>>> Also note that 'display-buffer' resizes a window iff that window is
>>> new or always has shown the buffer to display before.
>>>
>>> There's one thing about 'display-buffer-at-bottom' that stupefies me:
>>> Here
>>>
>>> 	     (let (split-width-threshold)
>>> 	       (setq window (window--try-to-split-window bottom-window alist)))
>>>
>>> we bind ‘split-width-threshold’ so we can split the bottom window into
>>> two side by side windows.  I recently found a branch of mine where I
>>> bind 'split-height-threshold' to nil instead and now cannot remember
>>> what we really wanted - split that window horizontally or vertically.
>>> Can you?  In either case feel free to change that to what you consider
>>> the more appropriate binding - maybe even binding both.
>>
>> It seems this code has no effect, it's never used.  Could you suggest
>> such window configuration to test that would call it?
>
> 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'.

>> There is another problem: in two small vertically split windows
>> 'display-buffer-at-bottom' sometimes displays the buffer in the
>> upper window.
>
> From judging the code I'd say this is impossible.  But with Emacs
> nothing is impossible.

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