From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Global bar to display global information Date: Tue, 16 Aug 2011 09:40:34 -0700 Message-ID: References: <87hb5he3dy.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1313512856 12630 80.91.229.12 (16 Aug 2011 16:40:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Aug 2011 16:40:56 +0000 (UTC) To: "=?iso-8859-1?Q?'=D3scar_Fuentes'?=" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 16 18:40:50 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QtMh7-0006eq-1S for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 18:40:49 +0200 Original-Received: from localhost ([::1]:58018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtMh6-0001aQ-LO for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 12:40:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtMh3-0001aJ-MQ for emacs-devel@gnu.org; Tue, 16 Aug 2011 12:40:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtMh2-0008EY-JF for emacs-devel@gnu.org; Tue, 16 Aug 2011 12:40:45 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:59960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtMh2-0008EU-A9 for emacs-devel@gnu.org; Tue, 16 Aug 2011 12:40:44 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7GGefw8022838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2011 16:40:43 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7GGeeYP002069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 16:40:41 GMT Original-Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7GGeZCU000385; Tue, 16 Aug 2011 11:40:35 -0500 Original-Received: from dradamslap1 (/10.159.52.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Aug 2011 09:40:35 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87hb5he3dy.fsf@wanadoo.es> Thread-Index: AcxcMDXvIy9Gu4LSRtaO1Y8pDePkxgAAD4hg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E4A9D8B.0058:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143315 Archived-At: > > This proposed feature is along the same lines. But this would not > > have as its goal to eliminate mode lines from individual > > windows. It would instead just free up some of that > > individual-window mode line space that might be used for global > > info (not specific to the given buffer/window). > > I'll appreacite such feature. > > Most of the time the minibuffer is an idle blank line at the bottom of > the frame. Using it for displaying some global info sounds quite > convenient. It could display the global info even while asking for > input, overwritting the area used by the info as necessary. Ouch! That's not what I meant at all. I would not want to see such info displayed in the minibuffer/echo area itself (too complex, confusing, distracting, messy, noisy). And we already have ways of posting text to the echo area (same space as minibuffer) when the minibuffer is inactive: `message'. That messages get replaced by later messages and by minibuffer input is just a further demonstration that using the minibuffer/echo area for this global info would be a bad idea. All I really meant was an analogy: In the same way that a standalone minibuffer frame lets you factor out the multiple minibuffers into a single one, so some kind of global mode line would let you factor out the common/global info from the multiple mode lines into a single one. Somewhere. The feature needs to be optional in any case (obviously). It could also be a user choice where to put this global/common mode line. Choices might be: a. In a standalone minibuffer frame (if it exists), in its own dedicated space within that frame (e.g. 1 line, 2 lines? extendable?), perhaps above the minibuffer/echo area. b. Standalone, in its own frame. c. As a separate line in some existing frame (but in only one). We'd need some way to let users (and Lisp code) choose which frame. d. ? ... (As a user, I would choose (a).) However, for (c), there would be the annoyance of not necessarily seeing the info whenever the frame in question is somewhat occluded by another frame. That could happen in (a) or (b) also, but there the frame could presumably be positioned so that it is generally visible. That's anyway what users (e.g. I) do now for a minibuffer frame. (Mine's across the bottom of the screen, and I generally fit other frames, by default, so they don't overlap it.) Another possibility here (for (a) & (b)) would be to provide an `always-on-top' frame parameter that would cause its frame to never be occluded by other (Emacs) frames (except possibly by another frame that also has non-nil `always-on-top').