GNU bug report logs - #33870
27.0.50; xref-goto-xref not configurable

Previous Next

Full log

Message #203 received at 33870 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 33870 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, joaotavora <at> gmail.com,
 dgutov <at> yandex.ru
Subject: Re: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.