Customizing the mode line

[Eli Zaretskii]

Do we have some convenient UI for customizing the mode line?  The user
manual doesn't mention any.

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.

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. -- these are banished off the edge of
the mode line, and cannot be consulted.  This effectively makes these
features unavailable, unless one is willing to make her frames
unreasonably wide or even full-screen.

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.

Can we make the mode line display more ergonomic, or at least more
customizable?  Should I file a "wish-list" bug for this?

[Juanma Barranquero]

On Fri, Oct 30, 2009 at 12:18, Eli Zaretskii <eliz@...> wrote:

> Can we make the mode line display more ergonomic, or at least more
> customizable?  Should I file a "wish-list" bug for this?

Yes, please.

    Juanma

[Stefan Monnier]

> 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

[Joakim Verona]

Eli Zaretskii <eliz@...> writes:

> Do we have some convenient UI for customizing the mode line?  The user
> manual doesn't mention any.
>
> 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.
>
> 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. -- these are banished off the edge of
> the mode line, and cannot be consulted.  This effectively makes these
> features unavailable, unless one is willing to make her frames
> unreasonably wide or even full-screen.
>
> 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.
>
> Can we make the mode line display more ergonomic, or at least more
> customizable?  Should I file a "wish-list" bug for this?

One thing adding to the problem is that a lot of information is repeated
in all modelines, where they could really live separately in a special
status window.

I tried adding functions to help with this problem, for instance the
"window groups" patch that let you keep a window on screen, that could
keep status info. This is currently unfinished.

Currently I just use this instead:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; modeline-depopulator
;;test little hack to see info in msg area
;;TODO  lan status
(require 'battery)
(require 'timeclock)
(defun modeline-depopulator ()
  (interactive)
  (message "%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)))
(global-set-key [f5] 'modeline-depopulator)


I press f5 when I want to know something I dont need to know all the
time, like time and date, time spent in a project, and battery status.

It is not distracting and it does in fact work surprisingly well.

>
--
Joakim Verona

[Eli Zaretskii]

> From: Stefan Monnier <monnier@...>
> Cc: emacs-devel@...
> Date: Fri, 30 Oct 2009 09:38:16 -0400
>
> > Should I file a "wish-list" bug for this?
>
> Yes, please

Done.

> > 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).

Right, I also think that both percentage and the line number is
redundant, and we could remove one of them, at least by default,
leaving an option to restore it for those who want that.

And "C-x l" could be enhanced to show more of that information.

> 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.

We could simply display only the major mode by default, and show the
rest in a tooltip, or with some easily-typed command.

> Maybe we should also come up with a scheme to shrink the displayed
> buffer-name if it exceeds some number of chars.

It should probably be moved to the right edge, because if it does not
show in full, or even not at all, it's not a disaster: the user
generally knows what buffer she is in.

> 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).

We could also make the mode line take 2 lines, but I think this would
be a big job, because I think various places in the display engine
assume it's only one line.

[Eli Zaretskii]

> From: joakim@...
> Date: Fri, 30 Oct 2009 16:01:42 +0100
> Cc: emacs-devel@...
>
> Currently I just use this instead:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; modeline-depopulator
> ;;test little hack to see info in msg area
> ;;TODO  lan status
> (require 'battery)
> (require 'timeclock)
> (defun modeline-depopulator ()
>   (interactive)
>   (message "%s\n%s\n%s"
>            (format-time-string "%H:%M %Y-%m-%d" (current-time))
>            (battery-format battery-echo-area-format (funcall
>                                                      battery-status-function))
>            (timeclock-status-string)))
> (global-set-key [f5] 'modeline-depopulator)
>
>
> I press f5 when I want to know something I dont need to know all the
> time, like time and date, time spent in a project, and battery status.

Perhaps we should have a command to show the entire mode-line string
in the echo area.  The echo area is not limited to a single line, so
it will show everything.

[Drew Adams]

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.

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@...>
> Cc: <emacs-devel@...>
> Date: Fri, 30 Oct 2009 09:54:18 -0700
>
> 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).

This could be solved by the menu we pop up when you click on the major
mode.  It could provide access to minor modes as well.

> 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.

This just means there should be an option to show the minor-mode
mnemonic, and that Icicles should turn it on.

> I disagree with Eli's suggestion of showing the whole mode line in the echo
> area.

That was meant as an addition to what the mode line shows, not as a
substitute for it.

[Chong Yidong]

Eli Zaretskii <eliz@...> writes:

> 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 major and minor mode indicators are important.  For instance, there
must be a visible indicator of whether overwrite mode is on, because if
you toggle it frequently, you may forget whether it's currently on.

> 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,

The gnus and rmail mode line formats definitely need to be improved, I
agree.

By the way, since we're complaining about the mode-line: I find the
sequence of "----" characters at the end of the mode-line hideous.  I
wouldn't object to removing them for graphical displays (they're
probably necessary for terminal displays).

[Stefan Monnier]

Drew Adams said:
> The general idea should be to shorten fields and change the existing
> tooltips,

I'm glad we agree.  Note that we'd also need to figure out a way to make
it work for ttys as well, where tooltips aren't available (probably
providing a command like "display-full-mode-line" to dump the modeline's
text into the (resizable) echo area, would be a good start).

Eli Zaretskii said:
> Right, I also think that both percentage and the line number is
> redundant, and we could remove one of them, at least by default,
> leaving an option to restore it for those who want that.

It's very tempting, but I can already hear screams in the distance.

> We could simply display only the major mode by default, and show the
> rest in a tooltip, or with some easily-typed command.

Maybe that'll be necessary, but if we can keep a few chars of each
minor-mode that would be better.

> It should probably be moved to the right edge, because if it does not
> show in full, or even not at all, it's not a disaster: the user
> generally knows what buffer she is in.

It's tempting, but I'm also weary of a potential rebellion.

> We could also make the mode line take 2 lines, but I think this would
> be a big job, because I think various places in the display engine
> assume it's only one line.

I think that should be kept as an absolute last resort: I don't want to
waste any more vertical space than the strict minimum, and really,
fundamentally, if we need to display so much information that we need
more than one line of mode-line, maybe we're doing something wrong (the
UI is overloaded).

Joakim Verona said:
> One thing adding to the problem is that a lot of information is repeated
> in all modelines, where they could really live separately in a special
> status window.

I don't use those global indicators specifically because I don't think
they belong in the mode-line.  I'm not opposed to code such as
display-battery-mode, but making it work well is not on my list
of priorities.


        Stefan

[Eli Zaretskii]

> From: Stefan Monnier <monnier@...>
> Date: Fri, 30 Oct 2009 15:12:40 -0400
> Cc: 'Eli Zaretskii' <eliz@...>, emacs-devel@...
>
> Eli Zaretskii said:
> > Right, I also think that both percentage and the line number is
> > redundant, and we could remove one of them, at least by default,
> > leaving an option to restore it for those who want that.
>
> It's very tempting, but I can already hear screams in the distance.

Yes, me too.  Which is why I would settle for easier customization,
which I can use when necessary.

> > It should probably be moved to the right edge, because if it does not
> > show in full, or even not at all, it's not a disaster: the user
> > generally knows what buffer she is in.
>
> It's tempting, but I'm also weary of a potential rebellion.

Ditto.

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Cc: emacs-devel@...
> Date: Fri, 30 Oct 2009 13:45:10 -0400
>
> The major and minor mode indicators are important.  For instance, there
> must be a visible indicator of whether overwrite mode is on, because if
> you toggle it frequently, you may forget whether it's currently on.

I agree that the overwrite mode should be visible.  But that doesn't
mean we need to see "Mail Fly Abbrev Fill" or their ilk in all other
modes.

Do you have instances other than the overwrite mode, which are
similarly important?  Or is that the only one?

[Lennart Borgman (gmail)]

On Fri, Oct 30, 2009 at 9:41 PM, Eli Zaretskii <eliz@...> wrote:

>> From: Chong Yidong <cyd@...>
>> Cc: emacs-devel@...
>> Date: Fri, 30 Oct 2009 13:45:10 -0400
>>
>> The major and minor mode indicators are important.  For instance, there
>> must be a visible indicator of whether overwrite mode is on, because if
>> you toggle it frequently, you may forget whether it's currently on.
>
> I agree that the overwrite mode should be visible.  But that doesn't
> mean we need to see "Mail Fly Abbrev Fill" or their ilk in all other
> modes.
>
> Do you have instances other than the overwrite mode, which are
> similarly important?  Or is that the only one?

There are similar things in Viper which probably should be moved into
the this new mode line handling too (when someone gets time to do it).

[Stephen Berman]

On Fri, 30 Oct 2009 17:25:27 +0200 Eli Zaretskii <eliz@...> wrote:

> Perhaps we should have a command to show the entire mode-line string
> in the echo area.  The echo area is not limited to a single line, so
> it will show everything.

FWIW, I use this:

(defun srb-display-mode-line-string (&optional arg)
  "Display the unpropertized mode-line string in the echo area.
With prefix argument ARG, insert it at point in the current buffer."
  (interactive "P")
  (let ((mode-line-string
         (eval-expression '(format-mode-line mode-line-format 0))))
    (and arg (insert mode-line-string))))
(global-set-key "\C-cf" 'srb-display-mode-line-string)

Steve Berman

[Stefan Monnier]

> The major and minor mode indicators are important.  For instance, there
> must be a visible indicator of whether overwrite mode is on, because if
> you toggle it frequently, you may forget whether it's currently on.

Agreed, which is also why I'd rather shorten them down to maybe even
a single char rather than eliminate them altogether.

> The gnus and rmail mode line formats definitely need to be improved, I
> agree.

Don't know about Rmail, but at least Gnus mode-lines haven't been
problematic for me.  The worst seems to be for message-mode, where the
buffer name tends to be long and the mode part says "(Message SC MML Fly
Abbrev Fill Narrow)": of those, "MML" should simply be removed because
it's not a major mode one should even be able to turn off (i.e. although
it's been implemented as a separate module, to the user, it's just an
integral part of message-mode), and Narrow should be eliminated by not
using narrowing (the narrowing is only used to hide a few headers,
namely (in my experience) "X-Draft-From:" and "References:").

> By the way, since we're complaining about the mode-line: I find the
> sequence of "----" characters at the end of the mode-line hideous.  I
> wouldn't object to removing them for graphical displays (they're
> probably necessary for terminal displays).

They are clearly needed for text terminals that don't support inverse
video, and may be occasionally vaguely useful even for text terminals
that do support inverse video, but for GUI terminals, they're just
a nuisance.


        Stefan

[Miles Bader-2]

Stefan Monnier <monnier@...> writes:

>> 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 very much like the percentages, scroll-bars or no.  Even if the
information presented is theoretically equivalent, I find the form
matters too.

> 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.

I agree, kinda... but... _some_ minor modes seem fairly important to
know about -- e.g., "Narrow", in a mode where narrowing isn't normal,
and "Fill" -- whereas others are less so.  Ideally, it would be possible
to see the "important" things, and replace the others with "..." or
whatever, but I'm not sure an easy way to distinguish them.

> 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).

That seems a very good idea.

-Miles

--
Marriage, n. The state or condition of a community consisting of a master, a
mistress and two slaves, making in all, two.

[mail-89]

Stefan Monnier <monnier@...> writes:
>> The major and minor mode indicators are important.  For instance, there
>> must be a visible indicator of whether overwrite mode is on, because if
>> you toggle it frequently, you may forget whether it's currently on.
>
> Agreed, which is also why I'd rather shorten them down to maybe even
> a single char rather than eliminate them altogether.

There's a diminish.el on emacswiki that can do this (though you must
specify which minor modes you'd like to shorten). I recently started
using it to get rid of modes like filladapt and outline, that I enable
globally, and my modeline is now usually less than 80 characters wide.

I've also removed the padding in mode-line-buffer-identification:

    (setq-default mode-line-buffer-identification
                  (propertized-buffer-identification "%b"))

and shortened the display-time format. These days it's largely only gnus
buffers and git branches with long names that make my mode line too
long.

[Miles Bader-2]

Chong Yidong <cyd@...> writes:
> By the way, since we're complaining about the mode-line: I find the
> sequence of "----" characters at the end of the mode-line hideous.  I
> wouldn't object to removing them for graphical displays (they're
> probably necessary for terminal displays).

They're rarely necessary for terminal displays either, because
reverse-video is used for the mode-line.

AFAIK, the dashes were basically intended for terminals like the vt52
which had no reverse-video, but the there's no significant usage of such
terminals today.

-Miles

--
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

[Manoj Srivastava-2]

On Fri, Oct 30 2009, Stefan Monnier wrote:

>> 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 am not a emacs developer, but as a long time user I would
 prefer to have the percentages instead of the scrollbar, if there were
 a choice (I know there is not). But I would much rather preserve the
 percentages.

        I also find the scrollbar somewhat confusing: When the end of
 buffer is visible in the window, I would expect the scrollbar to reach
 all the way to the bottom, but it does not.

> 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.

        How would this work on a non-windowed environment? Could a
 mechanism be devised to show the minor modes on user request, say, in
 the minibuffer?

        manoj
--
The major sin is the sin of being born. Samuel Beckett
Manoj Srivastava <srivasta@...> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: Eli Zaretskii <eliz@...>,  emacs-devel@...
> Date: Sat, 31 Oct 2009 14:16:47 +0900
>
> > 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.
>
> I agree, kinda... but... _some_ minor modes seem fairly important to
> know about -- e.g., "Narrow", in a mode where narrowing isn't normal,
> and "Fill" -- whereas others are less so.  Ideally, it would be possible
> to see the "important" things, and replace the others with "..." or
> whatever, but I'm not sure an easy way to distinguish them.

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.