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: Tue, 08 Jan 2019 10:24:25 +0100

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

Like 'display-buffer'.  But we don't call it 'display-buffer-maybe'.

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

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?

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

I'm not sure I understand you.  'display-buffer-fallback-action' is
always tried after everything else failed.  Would you want to run it
_before_ something else?

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

I now always display completions in a child frame so I never run into
practical problems with it.

> 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

Your bag of tricks is fathomless :-)  Basically, this means that
'display-buffer-in-previous-window' and 'display-buffer-at-bottom' are
inherently irreconcilable when a window was at bottom once and moved
upwards.  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?

martin






reply via email to

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