From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: moving window handling into lisp Date: Mon, 27 Jul 2009 17:32:33 +0900 Message-ID: Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248683583 32025 80.91.229.12 (27 Jul 2009 08:33:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 08:33:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 10:32:56 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVLdf-00077x-5f for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 10:32:56 +0200 Original-Received: from localhost ([127.0.0.1]:39694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVLde-0003PQ-C8 for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 04:32:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVLdX-0003Nj-NQ for emacs-devel@gnu.org; Mon, 27 Jul 2009 04:32:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVLdS-0003MD-Ic for emacs-devel@gnu.org; Mon, 27 Jul 2009 04:32:46 -0400 Original-Received: from [199.232.76.173] (port=48777 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVLdS-0003M1-Ex for emacs-devel@gnu.org; Mon, 27 Jul 2009 04:32:42 -0400 Original-Received: from tyo202.gate.nec.co.jp ([202.32.8.206]:62482) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVLdP-0002IO-Eb; Mon, 27 Jul 2009 04:32:40 -0400 Original-Received: from relay31.aps.necel.com ([10.29.19.54]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n6R8WYss014748; Mon, 27 Jul 2009 17:32:34 +0900 (JST) Original-Received: from relay21.aps.necel.com ([10.29.19.24] [10.29.19.24]) by relay31.aps.necel.com with ESMTP; Mon, 27 Jul 2009 17:32:34 +0900 Original-Received: from dhlpc061 ([10.114.113.45] [10.114.113.45]) by relay21.aps.necel.com with ESMTP; Mon, 27 Jul 2009 17:32:33 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id ADA6752E237; Mon, 27 Jul 2009 17:32:33 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop Original-Lines: 76 X-detected-operating-system: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113208 Archived-At: I'm kind of confused by what exactly is going to happen with windows (multiple competing vaguely-not-satisfying-and-confusing-at-least- to-my-simple-brain proposals...), but my impression is that it's desirable to have as much in lisp as possible. [I apologize if some of what I say below duplicates what's been said before; I often start zoning out when reading these long threads, and miss stuff!] The general approach I've always kind of assumed would be followed by any extension of window handling in emacs has a very simple basis (at least it _sounds_ simple :): ** Expose the (existing) window tree to lisp Basically keep the same window objects we have today, but allow lisp to get a handle on non-leaf window objects (today, AFAICT, lisp can only ever see leaf windows). Together with some low-level accessor/modifier functions, e.g. maybe: frame-root-window FRAME => ROOT-WIN window-children WINDOW => (LEFT-CHILD-WIN . RIGHT-CHILD-WIN) window-parent WINDOW => PARENT-WIN set-window-children WINDOW LEFT-CHILD-WIN RIGHT-CHILD-WIN (etc) A brief look suggests that much of the traditional window handling code (`window-list', `other-window', `split-window', `delete-window', `delete-other-windows', etc) could then be moved into lisp; none of that code looks very complicated or dangerous. With traditional user-level window handling functions in lisp, exploring various higher level window frameworks/abstractions seems to be easier. Of course the basic assumption is that what we really want is to make existing lisp windows a bit more malleable, rather than an entirely new infrastructure. ** Extending window handling As a separate layer on top of the above, my vague thinking is that the various fancy behaviors desired for things like ECB could be implemented as essentially hooks and window-properties etc that affect the typical user-level window functions (which are now lisp). For instance (these are simply rough ideas!): * A window-property which says "treat this window as the window root for purposes of C-x 1, C-x o, etc". Note that the new low-level primitive functions (which I listed above) _wouldn't_ be affected, and any lisp code that wants to see the raw tree, can do so. * A window property that says (somehow, not sure of the exact form) "When looking for a window leaf (C-x 0, C-x o, etc), use instead". * A buffer-local hook which gets run after setting a window's buffer to that buffer. (I guess window-configuration-change-hook covers this to some degree, but it can be annoying to use) [The first two properties probably would need some means of specifying different behaviors for different operations -- what you want to consider a "leaf" might be different depending on whether the user is moving amongst windows or deleting them.] Anyway, those are my vague ideas. I hope I'm not simply adding to the confusion... -miles -- Advice, n. The smallest current coin.