all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>,
	"'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: RE: Customizing the mode line
Date: Fri, 30 Oct 2009 09:54:18 -0700	[thread overview]
Message-ID: <AE55C830895044B7BF49FE2D5F37A20C@us.oracle.com> (raw)
In-Reply-To: <83pr84ewvj.fsf@gnu.org>

I disagree with these statements about minor-mode indicators:
 - once you've seen the list of minor modes, you don't need it anymore
 - only the major mode is needed in the mode line

Two reasons:

1. Access to the minor-mode menus (same as for the major mode).

2. Current minor-mode status. The minor-mode indicator (lighter) can be a way to
convey status. I use it that way in Icicles for instance, to tell users during
input: (a) whether completion is available, (b) input case-sensitivity, (c)
require-match, (d) multi-command completion.

The point about length of text is well taken, but it is fixed by fixing the
particular minor modes that use long lighters. Icicles uses only 3-4 chars to
convey all of the info mentioned above (#2). I'd suggest limiting lighters to 4
chars. But the tooltip should show the full mode name, not just `Minor Mode'.

Likewise, major-mode lighters should be short. There is no reason, for instance,
that Emacs-Lisp mode needs to have the lighter `Emacs-Lisp' instead of `Elisp'
or even `EL'. Other things too could be shortened without any real loss of
understanding. `Unix' for eol style need not take 4 chars. The general rule
should be for a tooltip to provide the full field info.

I would not object to providing #1 in some other way, at least for a global
minor mode (such as Icicles). Anything buffer-local should remain in the mode
line, however.

If we remove, by default, info that is not buffer-specific or window-specific
(e.g. time of day, global minor modes), there still needs to be the possibility
of showing such info somewhere continually. I'm thinking especially of
minor-mode status and menu access - showing status continually can be as
important for a global minor mode as for a process. The menu bar and tool bar
are no good for this. Global info need not be shown for each window or even for
each frame, but per-frame display is the most global thing we have so far.

The buffer name is often the longest field in the mode line. It could be greatly
shortened, with a tooltip for the full name. That would be better than moving it
to the right edge. This savings alone could make a big difference. Currently,
the tooltip for the buffer name says `Buffer name', instead of, e.g., `Buffer
vc-dispatcher.el'. That's a waste.

I would prefer that we keep the size indicator (e.g. `37%'), by default. In
general, we should take chars from the long fields such as buffer name, and not
eliminate such short indicators. If need be, we could put the size info on the
tooltip for the line number - they already share the same `mouse-1' menu.

I disagree with Eli's suggestion of showing the whole mode line in the echo
area. Many of us turn off `tooltip-mode'. Information should be available as a
tooltip for individual mode-line entries, which means that the echo area should
be usable for that when `tooltip-mode' is off. Anyway, when a user wants more
information than is visible in the mode line, s?he usually wants it for one
specific field.

The general idea should be to shorten fields and change the existing tooltips,
from simply letting you know what the field is for, to letting you know what the
field's full value is. We already do that for the first few fields (encoding,
eol style etc.). We should do it especially where it offers the greatest
abbreviation potential - e.g. buffer name.

I suggest that we start by (a) simply shortening existing fields, in particular
the buffer name and the mode-name lighters, and (b) providing full field info in
tooltips. I doubt we will even need to then consider removing some fields and
finding another (e.g. global) place for their info.





  reply	other threads:[~2009-10-30 16:54 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30 11:18 Customizing the mode line Eli Zaretskii
2009-10-30 11:28 ` Juanma Barranquero
2009-10-30 13:38 ` Stefan Monnier
2009-10-30 15:15   ` Eli Zaretskii
2009-10-30 16:54     ` Drew Adams [this message]
2009-10-30 17:18       ` Eli Zaretskii
2009-10-30 19:12       ` Stefan Monnier
2009-10-30 20:39         ` Eli Zaretskii
2009-10-31  5:16   ` Miles Bader
2009-10-31  8:47     ` Eli Zaretskii
2009-10-31 10:00       ` Juanma Barranquero
2009-10-31 16:03       ` Drew Adams
2009-10-31 16:29         ` Eli Zaretskii
2009-10-31 17:03           ` Drew Adams
2009-10-31  6:09   ` Manoj Srivastava
2009-10-31 10:31     ` Štěpán Němec
2009-10-31 20:38     ` Scrollbar thumbs (was: Customizing the mode line) Stefan Monnier
2009-11-01  3:11       ` Scrollbar thumbs Miles Bader
2009-11-02  6:55         ` Stefan Monnier
2009-11-02  7:41           ` Jason Rumney
2009-11-02 14:10             ` Stefan Monnier
2009-11-04 16:36   ` Customizing the mode line Evil Boris
2009-10-30 15:01 ` joakim
2009-10-30 15:25   ` Eli Zaretskii
2009-10-30 21:55     ` Stephen Berman
2009-10-30 17:45 ` Chong Yidong
2009-10-30 20:41   ` Eli Zaretskii
2009-10-30 20:56     ` Lennart Borgman
2009-10-31  0:13   ` Stefan Monnier
2009-10-31  5:17     ` Justin Bogner
2009-10-31  5:19   ` Miles Bader
2009-10-31 11:07 ` Richard Stallman
2009-10-31 11:19   ` Juanma Barranquero
2009-11-01  9:28     ` Richard Stallman
2009-11-01 15:21       ` Juanma Barranquero
2009-10-31 11:27   ` Eli Zaretskii
2009-10-31 14:09     ` Robert J. Chassell
2009-10-31 14:30       ` Eli Zaretskii
2009-10-31 22:13         ` Robert J. Chassell
2009-10-31 22:40         ` Robert J. Chassell
2009-11-01  3:49           ` Eli Zaretskii
2009-10-31 18:55       ` Juanma Barranquero
2009-10-31 17:46     ` M Jared Finder
2009-10-31 18:30       ` Eli Zaretskii
2009-10-31 19:02       ` Juanma Barranquero
2009-10-31 14:33 ` Chong Yidong
2009-10-31 15:45   ` Eli Zaretskii
2009-10-31 18:07     ` Chong Yidong
2009-10-31 18:21       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AE55C830895044B7BF49FE2D5F37A20C@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.