bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Wed, 09 Jan 2019 11:04:08 +0100

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

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

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

I can't tell because I'm not sure what we want here.  And if you say
that with your setup this part is never executed, things get even more
obscure.  So let's leave everything as it is until someone files a
"real" complaint.

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

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

martin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]