all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Joseph Brenner <doom@kzsu.stanford.edu>
To: help-gnu-emacs@gnu.org
Subject: Re: Window configuration
Date: Fri, 04 Jun 2010 11:10:49 -0700	[thread overview]
Message-ID: <87wruefz2u.fsf@kzsu.stanford.edu> (raw)
In-Reply-To: 87r5kpxkwz.fsf@fh-trier.de


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	other threads:[~2010-06-04 18:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.5.1274972891.6808.help-gnu-emacs@gnu.org>
2010-06-02 20:02 ` Window configuration Andreas Politz
2010-06-04 18:10   ` Joseph Brenner [this message]
2010-05-27 15:08 Gary .
2010-05-27 15:33 ` Drew Adams
2010-05-27 15:49   ` Drew Adams
2010-05-27 18:05     ` Drew Adams
2010-05-27 19:28   ` Gary
     [not found]   ` <mailman.4.1274988537.9628.help-gnu-emacs@gnu.org>
2010-05-28  0:52     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wruefz2u.fsf@kzsu.stanford.edu \
    --to=doom@kzsu.stanford.edu \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.