help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Window configuration


From: Joseph Brenner
Subject: Re: Window configuration
Date: Wed, 08 Dec 2010 15:11:49 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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.


reply via email to

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