From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Mon, 31 May 2010 19:28:21 +0200 Message-ID: <4C03F1B5.8040708@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1275326924 2435 80.91.229.12 (31 May 2010 17:28:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 17:28:44 +0000 (UTC) Cc: Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 19:28:43 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 1OJ8n3-0006Jz-UN for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 19:28:42 +0200 Original-Received: from localhost ([127.0.0.1]:44301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJ8n3-0003EQ-Be for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 13:28:41 -0400 Original-Received: from [140.186.70.92] (port=41676 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJ8mx-0003DT-Ak for emacs-devel@gnu.org; Mon, 31 May 2010 13:28:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJ8mw-0005Ps-9t for emacs-devel@gnu.org; Mon, 31 May 2010 13:28:35 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:34249) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OJ8mv-0005P8-RB for emacs-devel@gnu.org; Mon, 31 May 2010 13:28:34 -0400 Original-Received: (qmail invoked by alias); 31 May 2010 17:28:26 -0000 Original-Received: from 62-47-62-230.adsl.highway.telekom.at (EHLO [62.47.62.230]) [62.47.62.230] by mail.gmx.net (mp065) with SMTP; 31 May 2010 19:28:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18kYwITYagkU4VWJNjZJYELqp3cHFqpzmHs2WZ6/A Vm3EOB79nsawlw User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87632na2af.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 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:125401 Archived-At: > In the functions `buffer-list' and `other-buffer' the buffers in the > selected frame's `buffer-list' come first, followed by the rest of the > buffers from the global value of `buffer-list', and buffers from the > selected frame's parameters `buried-buffer-list' come last. > > Doing the same for the window-local parameter `buffer-list', > i.e. when `buffer-list' will return a list composed of > > window-local buffer-list > frame-local buffer-list > global buffer-list > frame-local buried-buffer-list > window-local buried-buffer-list > > then `quit-window' and all occurrences of `other-buffer' > in window handling code should do the right thing like > `view-return-to-alist' does (i.e. to get the right buffer). I've been looking into this now. `buffer-list' and `other-buffer' are currently in pretty bad shape so it's occasionally difficult to tell what they are supposed to do. Anyway, the three major obstacles to your approach seem: (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. (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. (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). martin