[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some question about display-buffer action functions

From: Juanma Barranquero
Subject: Re: Some question about display-buffer action functions
Date: Mon, 30 Jan 2012 22:26:43 +0100

On Mon, Jan 30, 2012 at 19:12, martin rudalics <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]