Some question about display-buffer action functions

Some question about display-buffer action functions

[Juanma Barranquero]

A long and boring and two just boring questions regarding the new
window machinery for display-buffer.


1)  [tl;dr: perhaps some sort of display-buffer hook (or hook actions)
would make action functions more flexible.]

I'm converting window-related functions from my .emacs to use
display-buffer's "action functions" (AF from now on), with the goal of
getting rid of as much custom code as possible, or at least converting
my custom ad hoc functions into more generic custom AFs. Ideally, the
AFs should be generic enough to be worthy candidates for inclusion in
future releases (for example,
display-buffer-choose-window-with-predicate).

A repeated problem I find is what to do when windows need to be set up
in some specific way; for example, to make them dedicated, or to add
my own window parameters.

[In the following example, I'm not claiming my setup is generally
useful to anyone else; I'm talking only about the "window setup"
problem.]

In most cases, I use a single-window configuration, except when I'm
developing code in a mode with an inferior process (sql, lisp, scheme,
python, and I also use ielm as "inferior mode" of elisp buffers). In
these cases, I split the frame in two windows, with the one above
(SUP) showing the code, and the one below (INF) showing the inferior
process. INF has a specific height, a window parameter that says that
it is to be used only for inferior processes, and it is strongly
dedicated, to prevent bs-cycle-*, which use "(switch-to-buffer next
nil t)", to switch buffers by accident.

Suppose I have a Python buffer in SUP, and no INF. Starting the
inferior process should create INF, and display *Python*. Now, in SUP
I switch to an SQL-mode buffer (INF is not affected). Starting the
MySQL inferior process generates and displays the *SQL* buffer, which
must appear in INF.

I have a custom AF called jb-inferior, and a function jb-setup which
sets up the window to my liking.

It seems straightforward to use display-buffer-alist for that, so I
add "*SQL*" and "*Python*" to that variable, with an AF of
jb-inferior.

Now, in an ideal world, after calling (pop-to-buffer BUFFER) for one
of these buffers, the process would be:

 - jb-inferior is called, looks for INF; if found and alive, use it,
and return INF; else return nil.
 - If nil, another, non-custom AF (likely
display-buffer-pop-up-window) will take care of selecting/creating the
appropriate window and returning it.
 - Then, call jb-setup for the window selected.

which is quite modular and elegant. But there's no way to call
jb-setup after selecting the window, at least not easily. I can think
of a few answers, but they start ugly and go down from there:

- Invoke pop-to-buffer (or display-buffer) from inside a custom
function, like this:

  (defun my-create-inferior-buffer-and-window (my-buffer)
    (pop-to-buffer my-buffer)
    (jb-setup (get-buffer-window my-buffer)))

 which will work in this particular case, but it's not a generic
answer in cases where display-buffer and friends are called from code
not under my control.

- Modify jb-inferior to always return a window, either finding INF or
spliting SUP, so it can run jb-setup before returning INF. This works
and it's easy, but it just kills modularity and elegance, and forces
jb-inferior to do a poor job of duplicating the work of the standard
AFs.

- Use window hooks (window-scroll-functions,
window-size-change-functions or window-configuration-change-hook),
which is not nice because the correspondence buffer<->window, known
while running display-buffer, is lost and has to be recomputed; and
additionally, these hooks run for every window created or buffer
displayed, which is wasted work.

- Or use a custom split-window-preferred-function. Most horrible
because it would destroy abstraction.

One possible answer would be having a
display-buffer-(after-)functions, which would get passed the buffer
and window after the window has been selected. (A -before-hook seems
less useful, and can be simulated with an AF which runs the code
you're interested and always return nil). Another one would be to have
a hook entry for the action alist (after-selecting-window-function or
somesuch) that would be run by the (custom and non-custom) AFs as the
last thing done upon selecting a window, just before returning it.


2)  Is there any way to set up the quit-window parameter of a window
so quit-window just always deletes the window? In the case above, when
I'm in INF and type quit-window I always want to destroy the window.
Even if INF was assigned to *Python* and then *SQL*, quit-window
should not go back to *Python*. Currently I'm forced to do

(defun jb-bury-interact (&optional finish)
  "Bury inferior interactive buffer.
If FINISH, terminate inferior process."
  (interactive "P")
  (unless (one-window-p t)
    (when finish (comint-send-eof))
    (bury-buffer)
    (window--delete nil t)))


3) It would be nice to make writing custom AFs simpler. Currently I'm
just ignoring the inhibit-same-window and reusable-frames actions in
my AFs (not to mention display-buffer-reuse-frames and pop-up-frames)
because it is a PITA to wrap your head around them...


    Juanma

Re: Some question about display-buffer action functions

[martin rudalics]

 > It seems straightforward to use display-buffer-alist for that, so I
 > add "*SQL*" and "*Python*" to that variable, with an AF of
 > jb-inferior.
 >
 > Now, in an ideal world, after calling (pop-to-buffer BUFFER) for one
 > of these buffers, the process would be:
 >
 >  - jb-inferior is called, looks for INF; if found and alive, use it,
 > and return INF; else return nil.
 >  - If nil, another, non-custom AF (likely
 > display-buffer-pop-up-window) will take care of selecting/creating the
 > appropriate window and returning it.

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.

 >  - Then, call jb-setup for the window selected.
 >
 > which is quite modular and elegant. But there's no way to call
 > jb-setup after selecting the window, at least not easily. I can think
 > of a few answers, but they start ugly and go down from there:
 >
 > - Invoke pop-to-buffer (or display-buffer) from inside a custom
 > function, like this:
 >
 >   (defun my-create-inferior-buffer-and-window (my-buffer)
 >     (pop-to-buffer my-buffer)
 >     (jb-setup (get-buffer-window my-buffer)))

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?

 >  which will work in this particular case, but it's not a generic
 > answer in cases where display-buffer and friends are called from code
 > not under my control.

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

 > - Modify jb-inferior to always return a window, either finding INF or
 > spliting SUP, so it can run jb-setup before returning INF. This works
 > and it's easy, but it just kills modularity and elegance, and forces
 > jb-inferior to do a poor job of duplicating the work of the standard
 > AFs.

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

 > - Use window hooks (window-scroll-functions,
 > window-size-change-functions or window-configuration-change-hook),
 > which is not nice because the correspondence buffer<->window, known
 > while running display-buffer, is lost and has to be recomputed; and
 > additionally, these hooks run for every window created or buffer
 > displayed, which is wasted work.

Neither of these hooks is appropriate here.

 > - Or use a custom split-window-preferred-function. Most horrible
 > because it would destroy abstraction.

Indeed.

 > One possible answer would be having a
 > display-buffer-(after-)functions, which would get passed the buffer
 > and window after the window has been selected.

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.

 > (A -before-hook seems
 > less useful, and can be simulated with an AF which runs the code
 > you're interested and always return nil). Another one would be to have
 > a hook entry for the action alist (after-selecting-window-function or
 > somesuch) that would be run by the (custom and non-custom) AFs as the
 > last thing done upon selecting a window, just before returning it.

It should probably be a `display-buffer-hook'.  But note that a hook
always requires people knowing how to write the corresponding function.
What about people who want to accomplish the necessary functionality via
the customization interface?

 > 2)  Is there any way to set up the quit-window parameter of a window
 > so quit-window just always deletes the window? In the case above, when
 > I'm in INF and type quit-window I always want to destroy the window.
 > Even if INF was assigned to *Python* and then *SQL*, quit-window
 > should not go back to *Python*. Currently I'm forced to do
 >
 > (defun jb-bury-interact (&optional finish)
 >   "Bury inferior interactive buffer.
 > If FINISH, terminate inferior process."
 >   (interactive "P")
 >   (unless (one-window-p t)
 >     (when finish (comint-send-eof))
 >     (bury-buffer)
 >     (window--delete nil t)))

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

 > 3) It would be nice to make writing custom AFs simpler. Currently I'm
 > just ignoring the inhibit-same-window and reusable-frames actions in
 > my AFs (not to mention display-buffer-reuse-frames and pop-up-frames)
 > because it is a PITA to wrap your head around them...

I'm by no means against a `display-buffer-hook'.  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))

martin

Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Sun, Jan 29, 2012 at 18:32, martin rudalics <rudalics@gmx.at> 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

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

Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Mon, Jan 30, 2012 at 11:21, martin rudalics <rudalics@gmx.at> 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

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

Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Mon, Jan 30, 2012 at 19:12, martin rudalics <rudalics@gmx.at> wrote:

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

Well, yes, but isn't that like doing dedication all over again?

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

Yes, I proposed such function one or two messages ago ;-)

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

I wanted to call it there, and also in case I do use quit-window interactively.

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

Suit yourself :-)

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

No, in the cases I was describing, choosing the window is generic, and
setting it up is specific of each use case.

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

I like that, but I think Stefan would dislike the added complexity.

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

Still, it seems quite flexible.

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

Yes, that's the least optimal answer.

    Juanma

Re: Some question about display-buffer action functions

[Stefan Monnier]

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

No, since that could cause it to pop up a new frame, whereas
bs-cycle-next is not about "I want to see this buffer" but "I want to
change this window's content", so popping up a new frame wouldn't help.


        Stefan

Re: Some question about display-buffer action functions

[Stefan Monnier]

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

Yes, we could generalize it to accept a predicate.

> 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 think it's a common-enough case to want to use a window for "this kind
of buffers only" (e.g. *diff* and *vc-diff*, or for *TeX-shell* and
*compilation*).


        Stefan

Re: Some question about display-buffer action functions

[martin rudalics]

 >> Another possibility would be to give the window a `no-switch-to-buffer'
 >> dedicated value and have `switch-to-buffer' / `display-buffer' observe
 >> that.
 >
 > Well, yes, but isn't that like doing dedication all over again?

It would be weaker than t and stronger than other non-nil values.

 >> Maybe a `display-buffer-in-window-with-predicate'
 >> would cover this.
 >
 > Yes, I proposed such function one or two messages ago ;-)

It was your proposal I had in mind.

 >> (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.
 >
 > Still, it seems quite flexible.

Let's add this for Emacs 24.2 then.

martin

Re: Some question about display-buffer action functions

[Juanma Barranquero]

On Tue, Jan 31, 2012 at 12:41, martin rudalics <rudalics@gmx.at> wrote:

> It would be weaker than t and stronger than other non-nil values.

Well, yes, but at the end, strong, weak, or intermediate dedications
are just ways to define how pop-to-buffer, switch-to-buffer, etc.
react when confronted with changing the buffer for that window. At
some point, wouldn't it just be easier to have an alist mapping
buffer-switching functions vs. dedication values, that each
buffer-switching function would look at? At a minimum, it would make
setup easier, I think.

> Let's add this for Emacs 24.2 then.

Great.

    Juanma

Re: Some question about display-buffer action functions

[martin rudalics]

 > At
 > some point, wouldn't it just be easier to have an alist mapping
 > buffer-switching functions vs. dedication values, that each
 > buffer-switching function would look at? At a minimum, it would make
 > setup easier, I think.

Currently, there are only two categories: `switch-to-buffer' and the
rest.  And IIUC Stefan wants to treat `switch-to-buffer' alikes just
like `set-window-buffer'.

martin