From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Mon, 31 May 2010 14:39:35 -0400 Message-ID: References: <4BB4CF6B.2000007@alice.it> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <871vdu6qn5.fsf@mail.jurta.org> <87bpcv1wvt.fsf@mail.jurta.org> <4BE13828.2030609@gmx.at> <87vdb2qo82.fsf@mail.jurta.org> <4BE27C17.3030005@gmx.at> <87vdav4vx5.fsf@mail.jurta.org> <4BE900E7.3090402@gmx.at> <87r5liqv8f.fsf@mail.jurta.org> <4BEA74DC.2060103@gmx.at> <87y6fns8qo.fsf@mail.jurta.org> <4BECF4D6.9030707@gmx.at> <87632na2af.fsf@mail.jurta.org> <4C03F1B5.8040708@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1275332220 21952 80.91.229.12 (31 May 2010 18:57:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 18:57:00 +0000 (UTC) Cc: Juri Linkov , Emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 20:56:58 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OJAAN-000787-DK for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 20:56:51 +0200 Original-Received: from localhost ([127.0.0.1]:56428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJAAM-0008Jj-PE for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 14:56:50 -0400 Original-Received: from [140.186.70.92] (port=47256 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJA42-0003th-PT for emacs-devel@gnu.org; Mon, 31 May 2010 14:50:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJ9ti-0002bL-Gn for emacs-devel@gnu.org; Mon, 31 May 2010 14:39:39 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:18978 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJ9ti-0002bG-Dl for emacs-devel@gnu.org; Mon, 31 May 2010 14:39:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF6fA0xMCpdY/2dsb2JhbACeMnK/Z4UWBIxM X-IronPort-AV: E=Sophos;i="4.53,335,1272859200"; d="scan'208";a="66394374" Original-Received: from 76-10-151-88.dsl.teksavvy.com (HELO pastel.home) ([76.10.151.88]) by ironport2-out.pppoe.ca with ESMTP; 31 May 2010 14:39:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 3854681F8; Mon, 31 May 2010 14:39:35 -0400 (EDT) In-Reply-To: <4C03F1B5.8040708@gmx.at> (martin rudalics's message of "Mon, 31 May 2010 19:28:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:125404 Archived-At: > (1) All calls to `other-buffer' for determining which buffer to show in > a window have the second argument nil. So if a buffer is already shown > in another window it's against some unwritten rule to show it in the > window in question again. If I follow that rule, then working with two > windows showing the same buffer remains just as tedious as it is now. Yes, the window handling code currently considers that the most likely thing the user wants is to see a buffer that's not currently shown. [ I'm not sure if it's careful to distinguish "shown on the current terminal" from "shown in some other terminal, miles away from here", which it should. ] This seems like a good default rule, so if we/you want to not follow this rule in some cases, we should think about how we can tell which is the better choice in a given situation. > (2) The length of frame-local buffer-lists is unbound. For a one-frame > user this already doubles the consing and maintenance overhead of buffer > lists without any gain. If we add window-local buffer-lists, we'd > double the current overhead once more for one window/one frame users. Is this overhead really significant? Say the list is 100 buffers long, that's 1 or 2 KB, right? Isn't this lost in the noise? > (3) For each buffer on the window-local buffer-list I'd have to maintain > its old point and its old window start position as markers. Otherwise > restoring the buffer would either get me a silly position if the buffer > was modified in the meantime (a rare case probably, but unacceptable > nevertheless) or a useless position like `point' (which would usually > coincide with `window-point' of some other window showing that buffer). > This means that for each buffer we get as many additional markers as > there are live windows in which the buffer was shown (times two). The use of `point' for that has not brought many complaints over the many years it's been used. Any reason to think it's a bad choice? Stefan "who coded up a hack for doc-view which preserves window-specific buffer-positions"