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: Fri, 18 Jun 2010 08:34:31 +0200 Message-ID: <4C1B1377.2020307@gmx.at> References: <4BB4CF6B.2000007@alice.it> <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> <4C19F6FB.6040203@gmx.at> <871vc5xugj.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 1276842887 9824 80.91.229.12 (18 Jun 2010 06:34:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Jun 2010 06:34:47 +0000 (UTC) Cc: Stefan Monnier , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 08:34:44 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 1OPVA3-0003to-OL for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 08:34:44 +0200 Original-Received: from localhost ([127.0.0.1]:50710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPVA3-0002pj-8M for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 02:34:43 -0400 Original-Received: from [140.186.70.92] (port=48684 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPV9x-0002nw-U1 for emacs-devel@gnu.org; Fri, 18 Jun 2010 02:34:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPV9w-0008Tf-HF for emacs-devel@gnu.org; Fri, 18 Jun 2010 02:34:37 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:53857) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OPV9w-0008TD-6v for emacs-devel@gnu.org; Fri, 18 Jun 2010 02:34:36 -0400 Original-Received: (qmail invoked by alias); 18 Jun 2010 06:34:32 -0000 Original-Received: from 62-47-39-174.adsl.highway.telekom.at (EHLO [62.47.39.174]) [62.47.39.174] by mail.gmx.net (mp053) with SMTP; 18 Jun 2010 08:34:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18NdmpktwsN2uM8VcJe2B546lh0DI2cpzSv9Chk4E 7eEnLkzTBNHlUt User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <871vc5xugj.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:126124 Archived-At: >> 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. > > I'm not sure this will be surprising because it will delete the window > when the Help buffer is displayed in it, not with some other buffer. > So when I see the Help buffer and type `q', I expect that it will delete > that window. My description was unclear. I meant: (1) Pop up the help window. (2) In that window display some other buffer. (3) Kill that other buffer. What Emacs now shall do with the window is unclear. If it does delete the window and step (3) happens some time after (1) the effect will be strange because the user already has forgotten about (1). If it does not delete the window the case where my step (3) is rewritten as (3') Switch back to the help buffer. will not delete the window. I solve this problem currently by checking whether the buffer in (3) is the buffer displayed by (1). But this doesn't solve the problem when (2) and (3) appear as (2") Reuse the window to display info. (3") Quit info. which likely should delete the window. [Note that making the help window weakly dedicated in step (1) will currently have (2") fail.] martin