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: Thu, 06 May 2010 09:04:37 -0400 Message-ID: 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> <4BE27C33.8000801@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1273151100 5060 80.91.229.12 (6 May 2010 13:05:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 6 May 2010 13:05:00 +0000 (UTC) Cc: Juri Linkov , Ken Hori , Emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 06 15:04:52 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 1OA0l1-0007RM-Mr for ged-emacs-devel@m.gmane.org; Thu, 06 May 2010 15:04:51 +0200 Original-Received: from localhost ([127.0.0.1]:37555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OA0l0-0004dB-TE for ged-emacs-devel@m.gmane.org; Thu, 06 May 2010 09:04:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OA0kv-0004bj-Pr for emacs-devel@gnu.org; Thu, 06 May 2010 09:04:45 -0400 Original-Received: from [140.186.70.92] (port=60273 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OA0ku-0004Ym-BJ for emacs-devel@gnu.org; Thu, 06 May 2010 09:04:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OA0ko-0003AU-CF for emacs-devel@gnu.org; Thu, 06 May 2010 09:04:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:40754 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OA0ko-0003AM-95 for emacs-devel@gnu.org; Thu, 06 May 2010 09:04:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPJa4kvO+IB1/2dsb2JhbACdZ3K9A4UTBIww X-IronPort-AV: E=Sophos;i="4.52,341,1270440000"; d="scan'208";a="63567022" Original-Received: from 206-248-128-117.dsl.teksavvy.com (HELO alfajor.home) ([206.248.128.117]) by ironport2-out.pppoe.ca with ESMTP; 06 May 2010 09:04:37 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 33DAFAF455; Thu, 6 May 2010 09:04:37 -0400 (EDT) In-Reply-To: <4BE27C33.8000801@gmx.at> (martin rudalics's message of "Thu, 06 May 2010 10:22:11 +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:124583 Archived-At: >> Interesting problem in itself, indeed. Luckily, I'm satisfied with the >> echo area for that purpose. Good luck! > The echo area sucks for two reasons: When you have windows above each > other and work in the upper one, your eyes have to continuously pass > through the lower window down to the echo area. What's worse, however, > is that the eldoc message obscures all sorts of other messages which is > particularly annoying when you want to read them during debugging. Yes, I'm not trying to argue it's perfect. Just that I'm satisfied for my own use. Of course we should try to minimize the number of cases where it hides useful info. One possibility is to try and provide better control so the user can prevent eldoc from showing up while she's reading a previous message, and so that she can remove the eldoc message to recover the previous message. > Having `set-window-configuration' "kill the window if the buffer died" > is not entirely trivial though. What kind of problems did you encounter (other than the one below)? > What shall we do when the last window has a deleted buffer? > Kill the frame? That could make sense, yes, since that's what would happen if the deletion had taken place while the frame was displayed. But we could also fallback to the current behavior in that corner case, since I'd assume it to be rare anyway (i.e. not worth spending too much time, at least for now). Stefan