From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Fri, 14 May 2010 01:46:35 +0300 Organization: JURTA Message-ID: <87y6fns8qo.fsf@mail.jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1273795271 28996 80.91.229.12 (14 May 2010 00:01:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 14 May 2010 00:01:11 +0000 (UTC) Cc: Ken Hori , Emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 14 02:01:10 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 1OCiKy-0006LD-HW for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 02:01:08 +0200 Original-Received: from localhost ([127.0.0.1]:44083 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCiKx-0007u1-Vx for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 20:01:08 -0400 Original-Received: from [140.186.70.92] (port=56386 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCiJ7-0006pc-L9 for emacs-devel@gnu.org; Thu, 13 May 2010 19:59:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCiJ2-0003ba-M6 for emacs-devel@gnu.org; Thu, 13 May 2010 19:59:13 -0400 Original-Received: from smtp-out2.starman.ee ([85.253.0.4]:54643 helo=mx2.starman.ee) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCiJ2-0003b2-CT for emacs-devel@gnu.org; Thu, 13 May 2010 19:59:08 -0400 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Original-Received: from mail.starman.ee (82.131.96.45.cable.starman.ee [82.131.96.45]) by mx2.starman.ee (Postfix) with ESMTP id 912183F40C6; Fri, 14 May 2010 02:59:03 +0300 (EEST) In-Reply-To: <4BEA74DC.2060103@gmx.at> (martin rudalics's message of "Wed, 12 May 2010 11:29:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:124753 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? I mean `quit-window' with non-nil argument KILL. When its argument KILL is nil (when the buffer is buried), the problem is the same. > 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. Yes, and occurrences of `(car (buffer-list))' are harmful too. > 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). It is sufficient because it stores this information in the buffer-local variable `view-return-to-alist'. I don't think a similar variable would help for other non-view buffers because it is specific to windows, not to buffers. So it seems a window parameter is more suitable. >> 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. I think it should be every action that changes the window's buffer. >> 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. No need to scan all windows' history stacks. During restoring the saved state from the stack, we could drop elements with killed buffers and continue popping the stack until we find an element with a live buffer. > But are we sure that a stack (a deque, rather) is sufficient? I think this window parameter should be treated like the frame parameter `buffer-list'. E.g. `other-buffer' prefers selected frame's buffer list instead of the global buffer list, etc. -- Juri Linkov http://www.jurta.org/emacs/