Re: Some question about display-buffer action functions

[martin rudalics]

> In that particular case, I'm not complaining about what bs-cycle-next
> does. If I invoke bs-cycle-next in INF, it's only by mistake (but a
> frequent one, because I use b-c-n all the time). As it is a mistake
> that annoys me, I make INF strongly dedicated to avoid it. I would
> prefer to make it softly dedicated, but that does not work currently.

Another possibility would be to give the window a `no-switch-to-buffer'
dedicated value and have `switch-to-buffer' / `display-buffer' observe
that.

> I would have preferred
> to write display-buffer-choose-window-with-parameter (an AF to choose
> a window according to some window parameter, passed through the action
> list), and then use that to implement my SUP/INF setup. Then, after
> 24.1, I would surely suggest that d-b-c-w-w-p could be a worthy
> addition to window.el. jb-inferior isn't ;-)

Sounds reasonable.  Maybe a `display-buffer-in-window-with-predicate'
would cover this.

>> And the buffer must be still the same too.  Maybe `quit-window' should
>> always delete the window if it's dedicated.
>
> That would work for me, but I'm not sure is the best answer.

`bury-buffer' does it.

> Well, yes. I don't do that, because I use a single keybinding (<f12>)
> that subsumes all this: If I'm in SUP and there's no INF, create INF.
> If I'm in SUP and there's an INF, switch to INF; and if I'm in INF,
> kill it, bury the buffer and get back to SUP. Of course the function
> bound to <f12> does use delete-window (or, in fact, window--delete).

Where do you call `quit-window' here?  Or did you want to call it here?

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

It would be easy to do that.  We would only have to decide on a name.

>> Why would calling `jb-setup' mean that `jb-inferior' _depends_ on it?
>
> Just that it makes harder to use jb-inferior for things other than SUP/INF.

And I thought that `jb-setup' would be the more general function.

>> 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'.
>
> That's what I'm trying to do in this discussion: find a way to run it
> once, *after* the window is chosen and set-window-buffer called. In my
> original message, I listed the ways I know to make that happen (hooks,
> advices, a wrapper function, etc.).

IIUC we have three reasonable ways to do it:

(1) Put all the things we want (like desired window size, dedicatedness,
    ...) into `display-buffer-alist'.  That's what my original idea was
    and it's downside is that it makes `display-buffer-alist' bloated -
    we would have to put all this into its documentation.

(2) Provide some sort of a hook within `display-buffer-alist'.  That's
    easy to document and allows to call a function only for buffers that
    want it.  The downside of this is that a user has to replicate it
    for each and every alist entry since entries are not merged.

(3) Provide a standard `display-buffer-functions' hook.  This means that
    the function called there has to handle every possible detail based
    on the window and the buffer's name.

> (Note that I already have implemented a strongly coupled
> jb-inferior/jb-setup, so this is not about how to fix my .emacs; it's
> about how to make AFs, and action lists, more useful and flexible.)

Sure.  But you would have to test the usability of this first.

martin