Window configuration

Window configuration

[Gary .]

I swear, if emacs "steals" a window to reuse for something else again,
I'm going to swing an axe at it.

Is there any way to specify that windows containing buffers which have
a certain mode should *never* be reused or closed unless specifically
by user action (for example visiting a new file from the window)?

RE: Window configuration

[Drew Adams]

> I swear, if emacs "steals" a window to reuse for something else again,
> I'm going to swing an axe at it.
> 
> Is there any way to specify that windows containing buffers which have
> a certain mode should *never* be reused or closed unless specifically
> by user action (for example visiting a new file from the window)?

Yes, make them dedicated windows.
See the Elisp manual, node `Dedicated Windows'.
See the Elisp manual, node `Choosing Window'.

The easiest way to do this is to use `special-display-regexps', giving it a
regexp that matches all buffer names. By default, a "special-display" buffer is
shown in a dedicated window.

RE: Window configuration

[Drew Adams]

> > I swear, if emacs "steals" a window to reuse for something 
> > else again, I'm going to swing an axe at it.
> > 
> > Is there any way to specify that windows containing buffers 
> > which have a certain mode should *never* be reused or closed
> > unless specifically by user action (for example visiting a
> > new file from the window)?
> 
> Yes, make them dedicated windows.
> See the Elisp manual, node `Dedicated Windows'.
> See the Elisp manual, node `Choosing Window'.
> 
> The easiest way to do this is to use 
> `special-display-regexps', giving it a
> regexp that matches all buffer names.  By default, a 
> "special-display" buffer is shown in a dedicated window.

I forgot to answer your question about making this mode-specific.  You can do
that using `set-window-dedicated-p' on a mode hook.  Or if all buffers in the
mode in question have a certain name pattern, then you can use
`special-buffer-regexps'.

RE: Window configuration

[Drew Adams]

> > > I swear, if emacs "steals" a window to reuse for something 
> > > else again, I'm going to swing an axe at it.
> > > 
> > > Is there any way to specify that windows containing buffers 
> > > which have a certain mode should *never* be reused or closed
> > > unless specifically by user action (for example visiting a
> > > new file from the window)?
> > 
> > Yes, make them dedicated windows.
> > See the Elisp manual, node `Dedicated Windows'.
> > See the Elisp manual, node `Choosing Window'.
> > 
> > The easiest way to do this is to use 
> > `special-display-regexps', giving it a
> > regexp that matches all buffer names.  By default, a 
> > "special-display" buffer is shown in a dedicated window.
> 
> I forgot to answer your question about making this mode-specific.
> You can do that using `set-window-dedicated-p' on a mode hook.
> Or if all buffers in the mode in question have a certain name
> pattern, then you can use `special-buffer-regexps'.

Or customize the mode-hook variable (e.g. `emacs-lisp-mode-hook') to add a
function like this:

(lambda ()
  (make-local-variable 'special-display-regexps)
  (add-to-list 'special-display-regexps ".*"))

FWIW, I filed an Emacs bug to improve the doc about this for users:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6280

Re: Window configuration

[Gary]

Drew Adams wrote:
>> Is there any way to specify that windows containing buffers which have
>> a certain mode should *never* be reused or closed unless specifically
>> by user action (for example visiting a new file from the window)?
>
> Yes, make them dedicated windows.
> See the Elisp manual, node `Dedicated Windows'.
> See the Elisp manual, node `Choosing Window'.

Wow! Thanks for all of your replies :)) Will try it out tomorrow, or
more likely next week. I'm sure I searched for something like "dedicated
window", but I suppose if I used a different word to "dedicated" I'd
have missed it.

-- 
Gary

Re: Window configuration

[Stefan Monnier]

> Wow! Thanks for all of your replies :)) Will try it out tomorrow, or
> more likely next week. I'm sure I searched for something like "dedicated
> window", but I suppose if I used a different word to "dedicated" I'd
> have missed it.

You may also check out display-buffer-mark-dedicated.


        Stefan

Re: Window configuration

[Andreas Politz]

"Gary ." <help-gnu-emacs@garydjones.name> writes:

> I swear, if emacs "steals" a window to reuse for something else again,
> I'm going to swing an axe at it.
>

I'd like to pick up on this, since I am frustrated with ,,windows
behavior'' as well.  Though I developed some rules via
`display-buffer-function', a lot of times I still feel at will of
the editor (Maybe it's time for the doctor again).

A couple of random border cases :

- Info popping up in the 53x9 calc trail buffer.

- Knowing that the next command will pop-up a buffer where I don't
  want it, but not being able to do something about it (w/o
  writing a strategy paper first).

- _Not_ knowing where the next command will pop-up a buffer.

- ,,Smart commands'' destroying my window layout.

I know C-x 1 will set me free, but lately I was thinking about
going the whole way and gain total control over buffer display
and window creation.

Maybe by defining a window layout, similar to gnus, first.  This
would express a finite set of possible windows, popping into
existence as needed.

Second a couple of rules, determining which buffer should be displayed
in what window.  This could be very simple or a playground for the
latest in AI.

My question is, did someone ,,go all the way'' and is able to give
some experiences ? Or do you have other, simpler strategies for dealing
with windows in a pleasant way ? Or is this something that never
bothered you before ?

-ap

Re: Window configuration

[Joseph Brenner]

Andreas Politz <politza@fh-trier.de> writes:
> "Gary ." <help-gnu-emacs@garydjones.name> writes:

>> I swear, if emacs "steals" a window to reuse for something else again,
>> I'm going to swing an axe at it.

> I'd like to pick up on this, since I am frustrated with ,,windows
> behavior'' as well.  Though I developed some rules via
> `display-buffer-function', a lot of times I still feel at will of
> the editor

I just ducked in here to ask this question from the other side, the
way things look from the programmer's point of veiw.

Pretty frequently when writing emacs lisp code, if I want to open
something in another window, I end up doing things that are very
quick-and-dirty, such as:

  (delete-other-windows)
  (split-window-vertically)

This completely takes control of the user's frame, and that's not
always necessary.  There might've been plenty of room in that frame
to just subdivide the current window, and I might've just blown away
a window that the user wanted to keep visible, for no good purpose.

Sometimes I need to open a small window adjacent to the current window
and the new window may only need a few lines.  I might do something like:

  (split-window-vertically 10)

That usually works okay, but it fails completely if there isn't enough
room in the display to get those ten lines.  (This problem frequently
pops up when I'm trying to use a large font size in order to do a demo.
Demo-only bugs are such a joy.)

What if you don't want to inflict things like this on the user?

> - Knowing that the next command will pop-up a buffer where I don't
>   want it, but not being able to do something about it (w/o
>   writing a strategy paper first).
>
> - _Not_ knowing where the next command will pop-up a buffer.
>
> - ,,Smart commands'' destroying my window layout.

It looks to me like you need to write a lot of custom code to do
sane emacs window management on top of everything else you're doing.

I've considered writing a window-gyrations.el package [1] a number of
times, but what I'd really like to hear is that someone has written
one already.

I'd also like to hear about window-handling policy suggestions for
elisp programmers.


[1] Just to make it absolutely clear: I'm not talking about the genre
of software that gives the user tools to move and resize windows and
switch buffers, I'm talking about a package of programmer's utilities to
make it easier to avoid infliciting unpleasant surprises.