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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 25 Dec 2018 20:53:01 UTC

Severity: minor

Found in version 27.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 33870 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, joaotavora <at> gmail.com, dgutov <at> yandex.ru
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Thu, 10 Jan 2019 01:40:41 +0200
>>>> 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'?




This bug report was last modified 6 years and 35 days ago.

Previous Next


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