pop-up-windows value to force a new window

pop-up-windows value to force a new window

[Drew Adams]

I don't see a good way to force `display-buffer' and related functions to
always use another window, even when there is more than one window displayed
currently. Is there some way (besides defining `display-buffer-function' in
such a way that it does this)?

What about letting a special non-nil value of `pop-up-windows', say
`new-window', cause this to happen? That is, if `pop-up-windows' =
`new-window', then `display-buffer', `pop-to-buffer', etc. would always use
a new window; they would never reuse an existing window.

This would let Lisp code, for example, bind to that value, and be sure that
`display-buffer' etc. will always create a new window. Subsequently deleting
that window will not leave fewer windows than before the display. IOW, this
would let you use `display-buffer' to always pop up an extra window.

This should have no effect on existing code (unless there is some code that
already uses that special value).

Re: pop-up-windows value to force a new window

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 2 Sep 2006 13:38:11 -0700
> 
> What about letting a special non-nil value of `pop-up-windows', say
> `new-window', cause this to happen?

is this really necessary so close to a pretest?

RE: pop-up-windows value to force a new window

[Drew Adams]

    > What about letting a special non-nil value of `pop-up-windows', say
    > `new-window', cause this to happen?

    is this really necessary so close to a pretest?

Sorry, do I need to prefix each feature suggestion with "for consideration
after the release", so close to a pretest? ;-)

Re: pop-up-windows value to force a new window

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>     > What about letting a special non-nil value of `pop-up-windows', say
>     > `new-window', cause this to happen?
>
>     is this really necessary so close to a pretest?
>
> Sorry, do I need to prefix each feature suggestion with "for consideration
> after the release", so close to a pretest? ;-)

Or save them for after the release---reading and evaluating feature
suggestions involves a non-zero amount of energy that could be used to
work on the pretest.

Re: pop-up-windows value to force a new window

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>     > What about letting a special non-nil value of `pop-up-windows', say
>>     > `new-window', cause this to happen?
>>
>>     is this really necessary so close to a pretest?
>>
>> Sorry, do I need to prefix each feature suggestion with "for consideration
>> after the release", so close to a pretest? ;-)
>
> Or save them for after the release---reading and evaluating feature
> suggestions involves a non-zero amount of energy that could be used to
> work on the pretest.

Agree!

Besides, it quite likely the suggestions will have been forgotten once we
release 22.1.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: pop-up-windows value to force a new window

[Stuart D. Herring]

> I don't see a good way to force `display-buffer' and related functions to
> always use another window, even when there is more than one window
> displayed
> currently. Is there some way (besides defining `display-buffer-function'
> in
> such a way that it does this)?

First, you need to define what "always use another window" means.  What if
the current frame is divided into so many windows (or is itself so small)
that no splitting can occur because of the minimum window size variables? 
What if the current frame is unsplittable (where you shouldn't split it
automatically), or worse is a minibuffer-only frame that you -can't-
split?

> This would let Lisp code, for example, bind to that value, and be sure
> that
> `display-buffer' etc. will always create a new window. Subsequently
> deleting
> that window will not leave fewer windows than before the display. IOW,
> this
> would let you use `display-buffer' to always pop up an extra window.

If you want to "not leave fewer windows", what you probably want is to
restore the window configuration.  If that's what you want, just do it:
use `current-window-configuration' and `set-window-configuration'.  (There
are a few other useful related functions which can be found with Apropos.)
 If it interests, I have written a small "temporary window configurations"
package which aims to automate that process.

Hope this helps,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: pop-up-windows value to force a new window

[Drew Adams]

    > I don't see a good way to force `display-buffer' and related
    > functions to always use another window, even when there is
    > more than one window displayed currently. Is there some way
    > (besides defining `display-buffer-function'
    > in such a way that it does this)?

    First, you need to define what "always use another window"
    means.  What if
    the current frame is divided into so many windows (or is itself
    so small)
    that no splitting can occur because of the minimum window size
    variables?
    What if the current frame is unsplittable (where you shouldn't split it
    automatically), or worse is a minibuffer-only frame that you -can't-
    split?

Yes, of course. Before heading down the highway, corner cases would need to
be dealt with.

    > This would let Lisp code, for example, bind to that value, and be sure
    > that
    > `display-buffer' etc. will always create a new window. Subsequently
    > deleting
    > that window will not leave fewer windows than before the display. IOW,
    > this
    > would let you use `display-buffer' to always pop up an extra window.

    If you want to "not leave fewer windows", what you probably want is to
    restore the window configuration.  If that's what you want, just do it:
    use `current-window-configuration' and
    `set-window-configuration'.  (There
    are a few other useful related functions which can be found
    with Apropos.)
     If it interests, I have written a small "temporary window
    configurations"
    package which aims to automate that process.

I don't really recall what I was trying to do. I believe that I started with
`with-output-to-temp-buffer', and I wanted to have it always open a new
window, so deleting that window would not reduce the original config. IIRC,
I tried to use `save-window-configuration' with it, but things didn't
proceed as I wanted. I don't remember the details, and I don't have time now
to look into it.