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: Customizing the mode line Date: Fri, 30 Oct 2009 09:38:16 -0400 Message-ID: References: <83skd1dta0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256914267 11690 80.91.229.12 (30 Oct 2009 14:51:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Oct 2009 14:51:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 30 15:51:00 2009 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.50) id 1N3sob-0005rB-OT for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 15:50:58 +0100 Original-Received: from localhost ([127.0.0.1]:60353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3sob-0001Gd-4d for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 10:50:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3rgT-000777-54 for emacs-devel@gnu.org; Fri, 30 Oct 2009 09:38:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3rgN-000760-84 for emacs-devel@gnu.org; Fri, 30 Oct 2009 09:38:28 -0400 Original-Received: from [199.232.76.173] (port=45034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3rgM-00075m-R5 for emacs-devel@gnu.org; Fri, 30 Oct 2009 09:38:22 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:40243 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3rgK-0004V2-EY; Fri, 30 Oct 2009 09:38:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAB2J6kpLd/xb/2dsb2JhbACBUOByhAsyBIhi X-IronPort-AV: E=Sophos;i="4.44,653,1249272000"; d="scan'208";a="48416130" Original-Received: from 75-119-252-91.dsl.teksavvy.com (HELO pastel.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 30 Oct 2009 09:38:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DF2CC80C9; Fri, 30 Oct 2009 09:38:16 -0400 (EDT) In-Reply-To: <83skd1dta0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Oct 2009 13:18:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.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:116462 Archived-At: > Can we make the mode line display more ergonomic, or at least more > customizable? I hope so, although I don't know how right now. > Should I file a "wish-list" bug for this? Yes, please (such requests have already appeared in the past, actually, tho it was before the bugtracker, I guess). > information that is much less important, like > the percentage of the file before the window start I indeed never look at it, but I'm uneasy removing it: basically I find it redundant when you have scrollbars, but in case you don't have scrollbars (e.g. in a non-GUI terminal) it's not redundant (but I got so used to using the scrollbars that it never occurs to me to look at the modeline for that info. Actually, I do look at the mode-line when I need to figure out "where am I" but then I look at the line number rather than the percentage). What do other people think about it? > I frequently find myself in a situation where the information that's > important to me is pushed beyond the right edge of the mode line, and > is thus invisible. Annoyingly, a large part of the real estate of the > mode line is taken by information that is much less important, like > the percentage of the file before the window start and the list of > minor modes in effect. The latter, for example, is quite static in > any given buffer, so once you saw it for the first time, there's no > need to continue showing it in such a central place. However, even in > a C buffer, the mode shown is "C/l Abbrev", which is quite long. And > when I read mail, I see something like "RMAIL XXXX/YYYY answered, > deleted"; when replying to mail it's "Mail Fly Abbrev Fill", etc. > These are very long strings that I don't need to see all the time, > because they almost never change. But they steal too much precious > space. I think the major-mode/minor mode display is important, but I agree that it often takes up a lot of space to display unchanging info. It would be good to come up with some way to make it more space efficient. Maybe we could replace "(Mail Fly Abbrev Fill)" with "(Mail..FAF)" and then expand the FAF to "Fly Abbrev Fill" in a tooltip. Maybe we should also come up with a scheme to shrink the displayed buffer-name if it exceeds some number of chars. > By contrast, dynamic information such as the current time, the system > load, the battery condition, the mail indicator, the current function > (when in which-func-mode), etc. I'd separate which-func-mode from the others because it is buffer-specific whereas the others are system-global, so the others really just shouldn't be displayed in each and every mode-line (that's a waste of very scarce resource). So there are two problems: - how/where to display global properties such as time, system load, mail indicator, ... - how to make sure which-func-mode gets displayed in a visible part of the modeline. Another thing we could consider is a generic "make the modeline fit" feature: after building the complete unshrunk modeline, we look at its length and if it exceeds the window's width, we shrink it "intelligently" (e.g. using shrink functions provided via text-properties on the various parts of the modeline). > I consider this a bad misfeature. What's more, modifying what's in > the mode line is not an easy task (unless I'm missing something): it > boils down to reading bindings.el and manually setting various parts > of standard-mode-line-* variables to remove or rearrange what is > shown. Yes, modifying the mode-line is a pain. I think it's more important to improve the default mode-line, but I agree that we also want to make it easier to customize it. Stefan