[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Customizing the mode line

From: Drew Adams
Subject: RE: Customizing the mode line
Date: Sat, 31 Oct 2009 09:03:42 -0700

> We can start by making a list of minor modes that are important.
> Right now, we have Ovwrt, Fill, Narrow, and some unspecified things in
> Viper.

No, let's start by throwing out the bathwater, not the baby.

As I said, we can start by:

a. Reducing the length of mode names that are long - both major and minor.
b. Improving tooltips to actually provide info about the current field value.
c. Perhaps reducing buffer-name length, when space becomes critical (i.e.

IOW, first get rid of extra, wasted space, and put the full info on tooltips, to
compensate. We may well find that there is no need to remove any fields, if
fields are shortened reasonably.

There is no reason that we abbreviate `Overwrite' as `Ovwrt' but we don't
abbreviate `Emacs-Lisp' to `Elisp' or even `EL'. There's no reason for long
lighters such as `Lisp Interaction' and `Dired by name'. They date from the days
when the mode line was the western wilderness; that territory has long since
been settled. And Eli needs room to park his mailbox+load-average+which-func

Currently there is wasted space just asking to be reclaimed - that's the place
to start, if we're worried about space on the default mode line. 4 or 5 chars
should be enough for any lighter - major or minor. `Narow' or `Nrw' - even
`Vipr'. `U' instead of `Unix'. And so on.

We should not remove any global-minor-mode lighters, as long as we haven't come
up with a good alternative for providing continual access to a 4-char status
indicator (lighter) somewhere, as well as access to the minor mode's menu.

Sticking all of the minor-mode menus on the same popup menu as the major mode is
not a great solution, but it could be done if we desperately need the space and
we find no other solution. (So far, we haven't even looked.) But there needs to
be some place where the equivalent of global-minor-mode lighters is displayed

Eli's original complaint said that things like minor-mode indicators and the
size indicator were crowding out stuff that he considers more important. As
examples of the latter he included time of day, a you've-got-mail indicator, and
which-func-mode help. More recently he added load-average to his list.

Those are things that are not even part of the default mode line! That means
changing the Emacs default mode line to fit one person's preferences and
customizations. And time of day, mail, and load-average are not even buffer- or
window-specific. They should be the first things to _remove_ from the default
mode line, if there were present.

If you turn on eldoc, which-func-mode, load-average display, mail notification,
and who knows what else, then sure, you might find that you are crowded for
space. But the solution to that problem is personal customization.

Which is one reason I support Eli's original request: easier customization of
the mode line. That is the solution for his personal difficulty - not removing
things like lighters and size indicator from the _default_ mode line.

[Eli, you even go so far as to say that your not being able to see which-func
help properly "clearly affects _our_ ability to work on improving Emacs".
Sheesh. You are an important developer, but you are only one user. The Emacs
mode line default should be designed for users (and not just one), not for

So there are two things we can do to improve the mode line, without losing
anything: (1) Shorten fields that are long and put the full field info on
tooltips. (2) Find a way to let users customize the mode line more easily.

Wrt #2, I don't have a solution, but it should be along the lines of providing
for prioritization: keep stuff as long as there is room, then progressively
remove stuff that the user has given lower priority.

But let's not confuse #1, improving the default, with #2, improving
customization. And in particular, let's _not start_ by removing any fields from
the default mode line.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]