From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: RE: Please review: Small fix for window.c Date: Thu, 9 Mar 2006 08:52:33 +0100 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1141890802 4780 80.91.229.2 (9 Mar 2006 07:53:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Mar 2006 07:53:22 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 09 08:53:19 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FHFxI-0006pl-V6 for ged-emacs-devel@m.gmane.org; Thu, 09 Mar 2006 08:53:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FHFxH-0002CA-Kx for ged-emacs-devel@m.gmane.org; Thu, 09 Mar 2006 02:53:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FHFww-0002C4-61 for emacs-devel@gnu.org; Thu, 09 Mar 2006 02:52:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FHFwt-0002Bs-7P for emacs-devel@gnu.org; Thu, 09 Mar 2006 02:52:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FHFwt-0002Bp-1Z for emacs-devel@gnu.org; Thu, 09 Mar 2006 02:52:39 -0500 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FHFzu-0004F2-0z for emacs-devel@gnu.org; Thu, 09 Mar 2006 02:55:46 -0500 Original-Received: by world1.sdm.de (MTA) via esmtp from mucns1.muc.sdm.de ([193.102.180.22]) id 1FHFwq-00088a-2y; Thu, 09 Mar 2006 08:52:36 +0100 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) id 1FHFwq-0005Aa-1O; Thu, 09 Mar 2006 08:52:36 +0100 Original-Received: from mucmail1.sdm.de ([193.102.180.175]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 08:52:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please review: Small fix for window.c Thread-Index: AcZC7pZUDfhHjYQsTbuEgnydMy/nkwAX4Ksg Original-To: , X-OriginalArrivalTime: 09 Mar 2006 07:52:35.0119 (UTC) FILETIME=[6D8E4BF0:01C6434E] 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:51399 Archived-At: Kim F. Storm wrote: > Stefan Monnier writes: >=20 >> A softly dedicated window is a window that's been created >> specifically=20 >> to display a particular buffer, but whose allegiance to this buffer >> may not be eternal. More specifically if the user decides to do >> switch-to-buffer, no error will be signalled and instead the >> dedication flag will simply be set to nil. This way, when the buffer >> gets deleted the window also gets deleted but only if the user hasn't >> used that window for some other purpose in the mean time. >>=20 >> With this scheme, pop-to-buffer would typically set the dedicated >> flag=20 >> of windows it creates to `soft', so many/most windows start out as >> being softly dedicated. >>=20 >> I hope I'll get enough time and motivation at some point to try and >> convince Emacs's maintainers that this is a good idea and should be >> installed.=20 >=20 > I think it sounds like an excellent idea! I second this... >=20 >> With soft-dedication, the use of set-window-configuration to try and >> undo what display-buffer has done is replaced by a call to >> kill-buffer=20 >> or bury-buffer. >=20 > Nice! >=20 >=20 > I was thinking about another kind of "hard" dedication -- where a > window cannot be deleted unless you kill the associated buffer. It > seems useful for stuff like ECB which don't want _anything_ to mess > with its windows. Yes, sounds like an excellent idea, different levels of dedication could solve the problems of tools like ECB and would allow to throw away a lot of advices currently necessary for ECB!