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: Wed, 12 May 2010 11:29:00 +0200 Message-ID: <4BEA74DC.2060103@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> 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 1273656559 3261 80.91.229.12 (12 May 2010 09:29:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 May 2010 09:29:19 +0000 (UTC) Cc: Ken Hori , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 12 11:29:18 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 1OC8Fi-0005ay-7g for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 11:29:18 +0200 Original-Received: from localhost ([127.0.0.1]:53362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC8Fh-00066v-EF for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 05:29:17 -0400 Original-Received: from [140.186.70.92] (port=54489 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC8FY-00066L-HR for emacs-devel@gnu.org; Wed, 12 May 2010 05:29:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OC8FT-0003QX-5u for emacs-devel@gnu.org; Wed, 12 May 2010 05:29:05 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:47503) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OC8FS-0003QA-Qo for emacs-devel@gnu.org; Wed, 12 May 2010 05:29:03 -0400 Original-Received: (qmail invoked by alias); 12 May 2010 09:29:01 -0000 Original-Received: from 62-47-41-249.adsl.highway.telekom.at (EHLO [62.47.41.249]) [62.47.41.249] by mail.gmx.net (mp044) with SMTP; 12 May 2010 11:29:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+EsdwlIBSEEdpyLPwQPNCNDDjUFNNln/e6m5avpH szU1ntSmDnXrJi User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87r5liqv8f.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:124720 Archived-At: >> ... where `quit-restore-window' here replaces `quit-window' which has >> too obscure semantics for my taste. And obviously, exiting `view-mode' >> calls `quit-restore-window' here too. > > Yes, `quit-window' is useless because it doesn't help to avoid the mess > that occurs after killing buffers. You don't mean buffers killed by `quit-window' but by some standalone `kill-buffer' I suppose? > Now do the same without using `view-mode' - visit a file in dired 1 with > RET, select the second window, visit another file in dired 2, select the > first window, kill the buffer, select the second window, kill the buffer: > > `RET C-x o RET C-x o C-x k C-x o C-x k' > > The window configuration is broken with original buffers exchanged > their windows: > > +---------+---------+ > | | | > | dired 2 | dired 1 | > | | | > | | | > +---------+---------+ The culprit here is the `other-buffer' call when unshowing the buffer. Practically all occurrences of `other-buffer' in window handling code are harmful. Their original purpose was to make sure that the same buffer isn't displayed twice on a frame I suppose. > 2. Another example - visit the same buffer in two windows, and put point > at different positions of the same buffer. > > +---------+---------+ > | | | > | dired 1 | dired 1 | > | | | > | | | > +---------+---------+ > > Now view a file in the first window, and quit: `v q'. > The window configuration is correctly restored > (without using `set-window-configuration') - good. > > Now do the same without `view-mode': `RET C-x k'. > Instead of the original buffer, some random buffer is displayed > in this window. That's probably the most annoying instance of this. For some magic reason Emacs assumes that people never want to simultaneously look at two distinct portions of the same buffer ;-) > It seems your implementation of `quit-restore-window' will fix this problem, > but I don't see how it will work without a window history as a list? It doesn't solve any of these problems yet because `dired-find-file' uses `switch-to-buffer' and in `switch-to-buffer' I don't record any information about the dired buffer. I obviously could do so easily but we'd have to find a general agreement first. And, for lack of a history, it works only for the last `display-buffer' action which is sufficient for view mode purposes (by reverting to the last buffer displayed before view mode was entered). > This list could be saved as a window parameter `window-history' where each > element is like you implemented for the `quit-restore' parameter. Yes. We have to agree that we pay for the costs of this though. > Then every switch-to-buffer could add a `quit-restore' element to the > window history parameter, We'd have to enumerate all actions that would add such an element. > and every kill-buffer could remove it from the > history stack (and call its function at the same time). `kill-buffer' would probably scan all live windows' history stacks. But are we sure that a stack (a deque, rather) is sufficient? martin