Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Mon, Jan 30, 2012 at 11:21, martin rudalics <address@hidden> wrote:

> Actually `bs-cycle-next' should use `pop-to-buffer-same-window'.

Perhaps. But we've already gone through a few iterations of what
bs-cycle-next should call ;-)

> OTOH I don't understand: You invoke bs from the INF window and get
> surprised that it wants to switch to another buffer there?

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.

> That's what side windows try to tackle (unless the user explicitly
> overrides it by interactively calling `switch-to-buffer' in such a
> window).

Aha, I see.

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

Well, that would help me, though I don't know if it is a very common
need. Dedicated windows do not seem to get much use yet in user code.

> I still don't understand why `jb-inferior' should not call `jb-setup'.
> After all there could be some setup specific to INF windows.

Because I did a poor job of explaining myself. I should not have used
my own case as an example. In my .emacs, jb-inferior calls jb-setup.
They are strongly coupled. That has forced me to *write* jb-inferior,
which is an AF for creating and setting up INF. 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 ;-)

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

I'm not enamoured of the hook idea. I just happen to think that being
forced to advise list-buffers is even worse. But you're the expert, I
trust you to find a better mechanism ;-)

> In
> particular, because the hook function would have to discriminate,
> probably based on the name of the window's buffer, how to proceed.

Yes. That's why I talked about "hook actions".

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

That would be very nice.

> And the buffer must be still the same too.  Maybe `quit-window' should
> always delete the window when it's dedicated.

That would work for me, but I'm not sure is the best answer.

>  But maybe you should
> rather use C-x 0 to get rid of a window for sure ;-)

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).
My comment was about a case where quit-window does not do what I
expect. However:

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

...perhaps I was sleeping the last time I tried it, because now it works.

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

Yes.

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

Not too strict, but it's preferable IMO.

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

> Would this mean that when I call `jb-setup' from `display-buffer-hook'
> displaying a buffer depends on `jb-setup'?

No, but it sets the window height and its dedicatedness. It's
un-useful, and even harmful, if I ever want to use it for anything
else. Generality is lost.

>> So, as currently implemented, either AFs are generic, and any window
>
> What does "generic" stand for in this context?

Useful to other people. Not tied to one user's specific details of
implementation. Like d-b-(pop-up|reuse|same|use-some)-window and
friends.

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

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

    Juanma