From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joseph Brenner Newsgroups: gmane.emacs.help Subject: Re: Window configuration Date: Fri, 04 Jun 2010 11:10:49 -0700 Message-ID: <87wruefz2u.fsf@kzsu.stanford.edu> References: <87r5kpxkwz.fsf@fh-trier.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291838089 12500 80.91.229.12 (8 Dec 2010 19:54:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 19:54:49 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 08 20:54:45 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQQ67-0000Ki-DH for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:54:44 +0100 Original-Received: from localhost ([127.0.0.1]:58497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQ66-0006Cq-RB for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 14:54:42 -0500 Original-Path: usenet.stanford.edu!newsfeed.berkeley.edu!ucberkeley!news.svpal.org!xmission!news.bbs-scene.org!Xl.tags.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.rawbandwidth!news.posted.rawbandwidth.POSTED!not-for-mail Original-NNTP-Posting-Date: Fri, 04 Jun 2010 13:10:02 -0500 Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:yndntb6tXPpoRL9DSw53czWsRnE= Original-Lines: 62 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 198.144.208.84 Original-X-Trace: sv3-6OGArgq2/t66cZRV2VOL85ybirdaLDHO6CuD67BWSCqSMXRw0Z3PmNAn9IHm/moqkN05zhsQtP57AwY!l0ERBst3yhayDMuWsPqqdo+lTgYQxm39nKd3QxX586guXDF8YyVzx1YPv1wm8tW5oLFlX55PG2I= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Original-Xref: usenet.stanford.edu gnu.emacs.help:178643 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75930 Archived-At: Andreas Politz writes: > "Gary ." 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.