Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Sun, Jan 29, 2012 at 18:32, martin rudalics <address@hidden> wrote:

> Basically that's what side windows should eventually do.  In your case
> the INF window would be the bottom side window with slot number zero.
> It's either reused or created and weakly dedicated so it's not reused by
> other buffer display functions.

As I said, weak dedication fails for the "(switch-to-buffer next nil
t)" call in bs-cycle-next. I'd like a style of dedication that said
"that window can only display a buffer from THIS list, and nothing
else".

> How is `my-create-inferior-buffer-and-window' different from
> `jb-inferior' (apart from the missing ALIST argument)?  Also, wouldn't
> `pop-to-buffer' (indirectly, via `display-buffer-alist') call
> `my-create-inferior-buffer-and-window' again?

In my example, jb-inferior is an AF, to be used from
display-buffer-alist. But my-create-inferior-buffer-and-window is not
an AF, it's a user command that I invoke through a keybinding to
create INF and display the inferior buffer. It relies on jb-inferior
being set up in display-buffer-alist. If jb-setup could be done via a
hook (or any other suitable method),
my-create-inferior-buffer-and-window wouldn't be required at all.

> I'm not sure I understand what you mean here: Shouldn't the setup of
> _any_ buffer appearing in INF be under your control via `jb-setup'?

Please, forget INF/SUP. Suppose I do "M-x list-buffers", and I've
customized display-buffer-alist for the "*Buffer List*" buffer, using
only standard AFs (the ones supplied with Emacs right now). How do I,
additionally, run a setup function to modify the window chosen by the
display-buffer call in list-buffers? Currently, I have to use window
hooks, or wrap list-buffers in a custom user command, or advice it.
(In fact, I use lot of advices just to run fit-window-to-buffer, which
is another example of the same problem.)

> Do you mean that jb-inferior cannot call `display-buffer-pop-up-window'
> or that it's clumsy to do that?

I mean that I'm being forced to decide in jb-inferior things that do
not really concern jb-inferior. AFs should ideally be able to either
choose and return a window, or return nil and pass the work to the
rest of AFs according to the user setup. If the current design forces
me to write custom AFs that always find and return a window, by hook
or by crook, OK, I can do that, but that's working against the spirit
of the feature, IMHO.

> Neither of these hooks is appropriate here.

Oh, I'm sure they could be beaten into submission; but I prefer not to
follow that route.

> It should be passed just the window after `set-window-buffer' since then
> the buffer can be easily derived from the window.  BTW `display-buffer'
> doesn't necessarily select the window.

You're right. Twice. :-)

> What about people who want to accomplish the necessary functionality via
> the customization interface?

Cannot answer that, as I try to avoid the customization interface as
much as possible.

> Calling (display-buffer-record-window 'window window buffer) from within
> `jb-inferior' should do that.

The code for quit-window does:

     ((and (not prev-buffer)
           (memq (nth 1 quit-restore) '(window frame))
           (eq (nth 3 quit-restore) buffer)
           ;; Delete WINDOW if possible.
           (window--delete window nil kill))

which doesn't kill if there's a previous buffer. But even doing

  (let ((w (get-buffer-window buffer))
        (window-size-fixed nil))
    (display-buffer-record-window 'window w buffer)
    (set-window-prev-buffers w nil)
    (window-resize w (- my-inferior-window-max-height
                        (window-total-height w))))

when I set up the window, quit-window still does not kill it.

My setup is a bit complex; I'll try to isolate a test case and file a bug.

> I'm by no means against a `display-buffer-hook'.

Note that my preferred fix is not a hook variable, but a hook action.

> But first I'd like to
> know why `display-buffer-alist' together with the ALIST argument cannot
> be used to do that without calling a hook function.  That is, why can't
> you do something like
>
> (defun jb-inferior (buffer alist)
>  (let ((window (window-with-parameter 'inferior-only)))
>    (if window
>        (set-window-buffer window buffer)
>      (setq window (display-buffer-pop-up-window buffer alist)))
>    (display-buffer-record-window 'window window buffer)
>    (jb-setup window)
>    window))

There are two reasons against that:

1) I'd prefer not to couple jb-inferior to
`display-buffer-pop-up-window'. As a principle, I don't think AFs
should call other AFs if possible. That's something for
display-buffer-alist and the other user-configurable options to
decide.

2) Because that makes jb-inferior depend on jb-setup, so any
generality is lost. Of course my jb-inferior example is anything but
generic (I said as much). But if I write a new AF
`display-buffer-choose-window-with-predicate', which understands
actions like `(predicate . (lambda (w) (>= (window-body-height w)
10)))', that's a completely generic AF, and it cannot depend on any
setup function.

So, as currently implemented, either AFs are generic, and any window
setup is done post-facto via hooks or the like, or they are strongly
coupled to the window they choose and generality is lost.

Hope I made myself clear.

Thanks for the effort in understanding my ramblings,

    Juanma