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: Thu, 17 Jun 2010 12:20:43 +0200 Message-ID: <4C19F6FB.6040203@gmx.at> References: <4BB4CF6B.2000007@alice.it> <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> <4C04D1BF.9070902@gmx.at> <4C052F8C.8030208@gmx.at> <87sk56sg6x.fsf@mail.jurta.org> <4C16616C.2070101@gmx.at> <87pqztiafa.fsf@mail.jurta.org> <4C1726D3.2090308@gmx.at> <87pqzsm2m6.fsf@mail.jurta.org> <4C1908ED.6090107@gmx.at> <878w6esntw.fsf@mail.jurta.org> <4C19D59E.5010402@gmx.at> <87sk4mowe8.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 1276770069 31759 80.91.229.12 (17 Jun 2010 10:21:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 10:21:09 +0000 (UTC) Cc: Stefan Monnier , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 17 12:21:08 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 1OPCDb-0003C0-Qb for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 12:21:08 +0200 Original-Received: from localhost ([127.0.0.1]:60680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPCDa-0003n3-7w for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 06:21:06 -0400 Original-Received: from [140.186.70.92] (port=53423 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPCDN-0003kI-9Y for emacs-devel@gnu.org; Thu, 17 Jun 2010 06:20:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPCDL-0000pT-Th for emacs-devel@gnu.org; Thu, 17 Jun 2010 06:20:53 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:59151) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OPCDL-0000p2-Hm for emacs-devel@gnu.org; Thu, 17 Jun 2010 06:20:51 -0400 Original-Received: (qmail invoked by alias); 17 Jun 2010 10:20:49 -0000 Original-Received: from 62-47-32-46.adsl.highway.telekom.at (EHLO [62.47.32.46]) [62.47.32.46] by mail.gmx.net (mp067) with SMTP; 17 Jun 2010 12:20:49 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19B6mZBlIdBoqMTDz4F0F+/cnFJfxyrFdE35S2oKR WXK2rhzTqbmezJ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87sk4mowe8.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:126074 Archived-At: > If frame-local buffer-lists are flawed, they should be fixed. > But I think window-local buffer-lists should be modelled after > frame-local buffer-lists. A frame-local buffer-list is a frame > parameter, ... implemented within the frame structure ... > so a window-local buffer-list could be a window parameter, > with more information associated with every element (window-start, > window-point, quit-restore function). > >> I suppose that for the moment I'll abandon the idea of window local >> buffer lists and return to them after I have solved some other issues. > > You will need window-local buffer-lists anyway to correctly restore > previous places when quitting the window. IOW, instead of > `quit-restore-window' parameter (that saves only 1 previous place), > you can add a window parameter `buffer-list' (and use it to restore > previous places when quitting) that later could combine its values > with frame-local `buffer-list' and global `buffer-list' for the > function `(buffer-list)'. Yes. But my `quit-restore-window' parameter was a very simple start. It doesn't use markers and doesn't do much when a window's buffer no longer equals that specified in the parameter. OTOH, `view-mode' has other pitfalls like the need for copying the parameter when splitting the window. >> The problem is that the information contained there might be already >> stale (the user might have done a lot of things in between). For help >> windows it makes sense to check whether the window still displays the >> help buffer and only if it does I proceed according to the information >> stored in the window parameter. For arbitrary buffers in non-dedicated >> windows I might just violate the principle of least surprise. > > I see no such problems for `view-return-to-alist', so maybe it won't > a problem for other buffers too. It does not have problems because you do it via `View-quit', hence the window is probably still the same window showing the same buffer. If you switch to another buffer in an earlier popped up help window, then having a later `unbury-buffer' delete that window might be surprising. martin