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: Fri, 04 Jun 2010 09:11:55 -0400 Message-ID: References: <4BB4CF6B.2000007@alice.it> <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> <4C04D1BF.9070902@gmx.at> <87hblmv9s3.fsf@mail.jurta.org> <4C0655D1.60205@gmx.at> <87eigps0gn.fsf@mail.jurta.org> <4C076E7A.8060803@gmx.at> <4C07CD7F.5010308@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1275657130 15653 80.91.229.12 (4 Jun 2010 13:12:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 4 Jun 2010 13:12:10 +0000 (UTC) Cc: Juri Linkov , Emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 04 15:12:07 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 1OKWgw-0005w6-BG for ged-emacs-devel@m.gmane.org; Fri, 04 Jun 2010 15:12:06 +0200 Original-Received: from localhost ([127.0.0.1]:39801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKWgv-0008Gb-Jh for ged-emacs-devel@m.gmane.org; Fri, 04 Jun 2010 09:12:05 -0400 Original-Received: from [140.186.70.92] (port=39333 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKWgn-0008Cg-Bi for emacs-devel@gnu.org; Fri, 04 Jun 2010 09:11:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKWgm-0006kv-7b for emacs-devel@gnu.org; Fri, 04 Jun 2010 09:11:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:15604 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKWgm-0006kl-5f for emacs-devel@gnu.org; Fri, 04 Jun 2010 09:11:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH+YCEzO+K4b/2dsb2JhbACeP3K/LoUXBIxf X-IronPort-AV: E=Sophos;i="4.53,361,1272859200"; d="scan'208";a="67290766" Original-Received: from 206-248-174-27.dsl.teksavvy.com (HELO pastel.home) ([206.248.174.27]) by ironport2-out.pppoe.ca with ESMTP; 04 Jun 2010 09:11:55 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 354C281F8; Fri, 4 Jun 2010 09:11:55 -0400 (EDT) In-Reply-To: <4C07CD7F.5010308@gmx.at> (martin rudalics's message of "Thu, 03 Jun 2010 17:42:55 +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:125507 Archived-At: >>> part of a frame's parameters. But an application should not be allowed >>> to alter the history of buffers shown on a particular frame. >> Why not? > Why should it lie? Histories should not be altered at will. This list is not a "sworn statement about history". It's just a data-structure where we record some state so as to help some heuristic make decisions. Modifying it won't get us trapped in a time warp. > But this is a minor issue. Hardly anyone knows that a frame's buried > buffer list can be altered, and which application would want to change > it anyway? It's only some wasted lines in the manual (just like those > for a frame's buffer-predicate). I don't have much opinion about whether it's worth mentioning in the manual, but I really can't think of any reason why we should prevent modification. Stefan