Re: Some question about display-buffer action functions

[martin rudalics]

> As I said, weak dedication fails for the "(switch-to-buffer next nil
> t)" call in bs-cycle-next.

I forgot that `switch-to-buffer' has

     ((eq (window-dedicated-p) t)

Actually `bs-cycle-next' should use `pop-to-buffer-same-window'.  I'm
still convinced that calling `switch-to-buffer' from Elisp is harmful.

OTOH I don't understand: You invoke bs from the INF window and get
surprised that it wants to switch to another buffer there?  But this is
inherently what you asked it to do, so the problem is more general.

> I'd like a style of dedication that said
> "that window can only display a buffer from THIS list, and nothing
> else".

That's what side windows try to tackle (unless the user explicitly
overrides it by interactively calling `switch-to-buffer' in such a
window).  Alternatively, one could make `set-window-dedicated-p' accept
a list of names of buffers that may replace the one currently shown in
the corresponding window.

> 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 still don't understand why `jb-inferior' should not call `jb-setup'.
After all there could be some setup specific to INF windows.

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

And I'm still not sure whether this should be done in a hook.  The fact
that we have to resort to a hook means the alist concept sucks.  In
particular, because the hook function would have to discriminate,
probably based on the name of the window's buffer, how to proceed.

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

Agreed.

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

I think that it should be possible to set up most properties of the
window used (like minimum or ideal size, fixed-sizeness, dedicatedness
to name a few) via `display-buffer-alist'.

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

And the buffer must be still the same too.  Maybe `quit-window' should
always delete the window when it's dedicated.  But maybe you should
rather use C-x 0 to get rid of a window for sure ;-)

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

That would be a bug.  If I do

(progn
  (display-buffer-record-window 'window nil (window-buffer))
  (set-window-prev-buffers nil nil))

in an arbitrary window, `quit-window' deletes it if there are other
windows around.

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

Please do.

>> I'm by no means against a `display-buffer-hook'.
>
> Note that my preferred fix is not a hook variable, but a hook action.

What is a "hook action"?  Do you mean that the function called should be
specified via `display-buffer-alist'?

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

I wouldn't be too strict about this.

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

Why would calling `jb-setup' mean that `jb-inferior' _depends_ on it?
Would this mean that when I call `jb-setup' from `display-buffer-hook'
displaying a buffer depends on `jb-setup'?  So far I thought that
`jb-setup' would only do some additional adjustments after a suitable
window has been found.  If it fails, the window is still around and
returned.

> So, as currently implemented, either AFs are generic, and any window

What does "generic" stand for in this context?

> setup is done post-facto via hooks or the like, or they are strongly
> coupled to the window they choose and generality is lost.

Do you mean that we should avoid here to invoke `jb-setup' twice - once
directly in an AF like `jb-inferior' and once via a hook?  But this
should be addressed by the coder of `jb-inferior'.

martin