Customizing the mode line

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?

Re: Customizing the mode line

[Juanma Barranquero]

On Fri, Oct 30, 2009 at 12:18, Eli Zaretskii <eliz@gnu.org> 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

Re: Customizing the mode line

[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

Re: Customizing the mode line

[joakim]

Eli Zaretskii <eliz@gnu.org> 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

Re: Customizing the mode line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> 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.

Re: Customizing the mode line

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Fri, 30 Oct 2009 16:01:42 +0100
> Cc: emacs-devel@gnu.org
> 
> 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.

RE: Customizing the mode line

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

Re: Customizing the mode line

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> 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.

Re: Customizing the mode line

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> 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).

Re: Customizing the mode line

[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

Re: Customizing the mode line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 30 Oct 2009 15:12:40 -0400
> Cc: 'Eli Zaretskii' <eliz@gnu.org>, emacs-devel@gnu.org
> 
> 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.

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> 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?

Re: Customizing the mode line

[Lennart Borgman]

On Fri, Oct 30, 2009 at 9:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Cc: emacs-devel@gnu.org
>> 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).

Re: Customizing the mode line

[Stephen Berman]

On Fri, 30 Oct 2009 17:25:27 +0200 Eli Zaretskii <eliz@gnu.org> 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

Re: Customizing the mode line

[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

Re: Customizing the mode line

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

Re: Customizing the mode line

[Justin Bogner]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

Re: Customizing the mode line

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> 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.

Re: Customizing the mode line

[Manoj Srivastava]

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@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Customizing the mode line

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> 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.

Re: Customizing the mode line

[Juanma Barranquero]

The discussion is centered in making room in the modeline, and that is good.

But I'm also interested in ways to make mode-line customization (from
elisp, not M-x customize) easier. Currently I have things like this in
my .emacs:

 (setcar (cdddr (cadadr (cadadr mode-line-client))) (propertize " "
'face 'variable-pitch))
 (setf (cadr (assq :propertize mode-line-modes))
       '(overwrite-mode
         ;; etc))

and it ain't pretty (and it is quite fragile, of course).

Perhaps a way to access its content similar to menus could be made to
work; currently, some things are in variables, some are not, and there
are cases where you want to add some tiny thing (like spacing around a
value), and in order to keep the text properties (tooltips, etc)
you've got to copy a bunch of stuff.

    Juanma

Re: Customizing the mode line

[Štěpán Němec]

On Sat, Oct 31, 2009 at 01:09:43AM -0500, Manoj Srivastava wrote:
> 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.
> 
+1
I would prefer the percentage, too, at least with the current weird
scrollbar behaviour.

> > 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@acm.org> <http://www.golden-gryphon.com/>  
> 1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
> 
> 
> 

Re: Customizing the mode line

[Richard Stallman]

I don't think that a better UI for customizing the mode line is a
really important place to improve.  Customizing it is not that hard to
do.

Let's spend our time working on features that will enable Emacs to do
things that it currently cannot do, and handle situations it currently
cannot handle.

Re: Customizing the mode line

[Juanma Barranquero]

> I don't think that a better UI for customizing the mode line is a
> really important place to improve.

I don't know whether it is "really important". I know that my
customizations break almost every time someone changes the default
mode-line.

>   Customizing it is not that hard to do.

I'm not sure what do you mean here by "customizing". Certainly,

  (setcar (cdddr (cadadr (cadadr mode-line-client))) ...)

is not "hard", but it is not evident either.

    Juanma

Re: Customizing the mode line

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 07:07:44 -0400
> 
> I don't think that a better UI for customizing the mode line is a
> really important place to improve.  Customizing it is not that hard to
> do.

??? Really?  Then please describe how to do that.  What user options
are available for that, and what values one should give them for the
following use-cases:

 . Show only the major mode, not the minor modes.

 . Remove the percent/All/Top/Bot part.

 . Display the load-average and the Mail notification between the line
   number and the major/minor mode indicator.

> Let's spend our time working on features that will enable Emacs to do
> things that it currently cannot do, and handle situations it currently
> cannot handle.

You seem to say, in effect, that features which use the mode line are
not important enough to discuss.  If so, I certainly disagree.  The
system load is very important to me when I get sluggish response from
Emacs: it allows me to figure out if my net connection is the
culprit.  The mail notification is very important to me as well, for
obvious reasons.

Btw, my complaint was triggered by the need to see the current
function (displayed by which-func-mode) when I was studying the
display engine code for my bidi work.  So this problem clearly affects
our ability to work on improving Emacs in other areas, certainly so
for me.

Re: Customizing the mode line

[Robert J. Chassell]

    > I don't think that a better UI for customizing the mode line is a
    > really important place to improve.  Customizing it is not that hard to do.

    ??? Really?  Then please describe how to do that.  

I have the following in my .emacs file and am not as good a programmer as
Eli Zaretski:

  (setq default-mode-line-format
   (quote
    (#("-" 0 1
       (help-echo
        "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
     mode-line-mule-info
     mode-line-modified
     mode-line-remote
  ;;   mode-line-frame-identification
  ;;   "`"
  ;;   (:eval  (user-real-login-name))
  ;;   "' "
     "  "
     mode-line-buffer-identification
     #("  " 0 2
       (help-echo
        "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
     (:eval (user-real-login-name))
     "@"
     default-directory
     #(" " 0 1
       (help-echo
        "mouse-1: select window, mouse-2: delete others, mouse-3: delete"))
     (size-indication-mode
      (6
       #(" %I " 0 4
         (help-echo "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete this"))))
  ;;    (if (string= (cdr (assq 'name (frame-parameters)))
  ;;                 (or "Root Emacs 22" "Bobs Emacs 22"))
     (line-number-mode "Line %l")
     (vc-mode vc-mode)
     (:propertize
      (" (" mode-name mode-line-process minor-mode-alist)
      help-echo "mouse-3: minor mode menu" local-map
      (keymap
       (header-line keymap
                    (down-mouse-3 . mode-line-mode-menu-1))
       (mode-line keymap
                  (down-mouse-3 . mode-line-mode-menu-1))))
  ;; the following is replaced by    the :propertize expression above
  ;;    #(" %[(" 0 4                    ; 4 is number of chars between quotes
  ;;      (help-echo
  ;;       "mouse-1: select window, mouse-2: delete others, mouse-3: delete"))
  ;;

  ;;    (:eval (mode-line-mode-name))
  ;;    mode-line-process
  ;;    minor-mode-alist
     #("%n" 0 2 (help-echo "mouse-2: widen" local-map (keymap ...)))
     ")%] "
     (-3 . "%P")
     global-mode-string
  ;;   "-%-"
    )))

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customizing the mode line

[Eli Zaretskii]

> From: bob@gnu.org (Robert J. Chassell)
> Date: Sat, 31 Oct 2009 14:09:23 +0000
> Cc: bob@gnu.org
> 
>     > I don't think that a better UI for customizing the mode line is a
>     > really important place to improve.  Customizing it is not that hard to do.
> 
>     ??? Really?  Then please describe how to do that.  
> 
> I have the following in my .emacs file and am not as good a programmer as
> Eli Zaretski:

That's just a copy of what bindings.el has, with some changes.  It may
be suited for .emacs, when you want to change the mode line once and
for all.

What I was after were _user_options_ that can be set for when I want
to change the mode-line appearance temporarily.

Re: Customizing the mode line

[Chong Yidong]

Here's one small simplification to the mode-line that we can easily
introduce: define a variable mode-line-help-echo, which serves as the
default help echo for any mode-line element not having its own
help-echo.

Now, bindings.el won't need to manuall apply the default help-echo to
"neutral" mode-line elements like spaces.  This makes the value shown in
`C-h v mode-line-format' less of a mess:

Value:
("%e-" mode-line-mule-info mode-line-client mode-line-modified mode-line-remote mode-line-frame-identification mode-line-buffer-identification "   " mode-line-position
 (vc-mode vc-mode)
 "  " mode-line-modes
 (which-func-mode
  ("" which-func-format "--"))
 (global-mode-string
  ("" global-mode-string "--"))
 "-%-")

Do you think that helps?


*** emacs/src/xdisp.c.~1.1316.~	2009-10-22 10:28:39.000000000 -0400
--- emacs/src/xdisp.c	2009-10-31 10:24:42.000000000 -0400
***************
*** 230,235 ****
--- 230,236 ----
  
  extern Lisp_Object Qface;
  extern Lisp_Object Qmode_line, Qmode_line_inactive, Qheader_line;
+ Lisp_Object Vmode_line_help_echo;
  
  extern Lisp_Object Voverriding_local_map;
  extern Lisp_Object Voverriding_local_map_menu_flag;
***************
*** 23421,23426 ****
--- 23422,23429 ----
        if (NILP (help))
  	{
  	  help = Fget_text_property (pos, Qhelp_echo, string);
+ 	  if (NILP (help) && !NILP (Vmode_line_help_echo))
+ 	    help = Vmode_line_help_echo;
  	  if (!NILP (help))
  	    {
  	      help_echo_string = help;
***************
*** 24914,24919 ****
--- 24917,24930 ----
  `header-line', or `menu' respectively.  */);
    mode_line_inverse_video = 1;
  
+   DEFVAR_LISP ("mode-line-help-echo", &Vmode_line_help_echo,
+ 	       doc: /* Default help-echo (tooltip) for mode-line elements.
+ This help-echo applies to any mode-line elements lacking a `help-echo'
+ property (see `mode-line-format'.  */);
+   Vmode_line_help_echo = build_string ("mouse-1: Select (drag to resize)\n\
+ mouse-2: Make current window occupy the whole frame\n\
+ mouse-3: Remove current window from display");
+ 
    DEFVAR_LISP ("line-number-display-limit", &Vline_number_display_limit,
      doc: /* *Maximum buffer size for which line number should be displayed.
  If the buffer is bigger than this, the line number does not appear

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 10:33:45 -0400
> 
> Here's one small simplification to the mode-line that we can easily
> introduce: define a variable mode-line-help-echo, which serves as the
> default help echo for any mode-line element not having its own
> help-echo.
> 
> Now, bindings.el won't need to manuall apply the default help-echo to
> "neutral" mode-line elements like spaces.  This makes the value shown in
> `C-h v mode-line-format' less of a mess:
> 
> Value:
> ("%e-" mode-line-mule-info mode-line-client mode-line-modified mode-line-remote mode-line-frame-identification mode-line-buffer-identification "   " mode-line-position
>  (vc-mode vc-mode)
>  "  " mode-line-modes
>  (which-func-mode
>   ("" which-func-format "--"))
>  (global-mode-string
>   ("" global-mode-string "--"))
>  "-%-")
> 
> Do you think that helps?

Sorry, I do not follow: which problem is this supposed to help with,
and how?

(There are too many different issues discussed in this thread, so it's
really hard to know which one you are trying to solve.)

Thanks.

RE: Customizing the mode line

[Drew Adams]

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

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

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

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

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.

Re: Customizing the mode line

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <emacs-devel@gnu.org>
> Date: Sat, 31 Oct 2009 09:03:42 -0700
> 
> `U' instead of `Unix'.

This one can be customized with eol-mnemonic-unix, so it's not a
problem.  (I have it customized to just "/".)  The non-native
mnemonics (Unix on DOS/Windows, DOS on Unix, etc.) are explicit
because users demanded that back when EOL decoding was introduced in
Emacs 20.  Maybe there's no need to do this anymore, but OTOH maybe
there will be a rebellion.

RE: Customizing the mode line

[Drew Adams]

> > `U' instead of `Unix'.
> 
> This one can be customized with eol-mnemonic-unix, so it's not a
> problem.  (I have it customized to just "/".)  The non-native
> mnemonics (Unix on DOS/Windows, DOS on Unix, etc.) are explicit
> because users demanded that back when EOL decoding was introduced in
> Emacs 20.

Good to know; thanks.

But we could instead use a shorter form for the default, and let users customize
it to something longer if they like.

> Maybe there's no need to do this anymore, but OTOH maybe
> there will be a rebellion.

Dunno about possible rebellions, but the place to start is to provide full field
info in tooltips. The tooltip for eol style is already fixed in this regard.


In general, we should start with the smallest changes that bring the greatest
benefit. In order:

1. Fix tooltips to convey full field/state info. Currently, most simply show the
name of the field.

2. _After_ that, think about shortening some of the long mode indicators. Both
major and minor - major-mode indicators are generally the longest, and sometimes
gratuitously long. With meaningful tooltips, all that's needed for the indicator
itself is, well, a brief indicator (!) - just a reminder, not an explanation.


These small changes will take us a long way toward freeing up space, I predict.
And with no significant information loss.

_After_ #1 and #2, if need be (and I don't really expect the need), we can get
down to discussing what else might be done, to free up yet more space.

Re: Customizing the mode line

[M Jared Finder]

Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> CC: emacs-devel@gnu.org
>> Date: Sat, 31 Oct 2009 07:07:44 -0400
>>
>> I don't think that a better UI for customizing the mode line is a
>> really important place to improve.  Customizing it is not that hard to
>> do.
> 
> ??? Really?  Then please describe how to do that.  What user options
> are available for that, and what values one should give them for the
> following use-cases:

The first two are easy.

>  . Show only the major mode, not the minor modes.

(setq minor-mode-alist nil) or customize mode-line-modes

>  . Remove the percent/All/Top/Bot part.

Remove the first two entries of mode-line-position


>  . Display the load-average and the Mail notification between the line
>    number and the major/minor mode indicator.

Reordering the mode line is much harder (and would be greatly 
appreciated by me).  I think if you cleaned up mode-line-format so that 
it only included VARIABLES, then this would be clear as day.  Right now 
mode-line-format's default value is big and scary (note, from Emacs22):

("%e"
  #("-" 0 1
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-mule-info mode-line-modified mode-line-frame-identification 
mode-line-buffer-identification
  #("   " 0 3
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-position
  (vc-mode vc-mode)
  #("  " 0 2
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-modes
  (which-func-mode
   ("" which-func-format
    #("--" 0 2
      (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))))
  (global-mode-string
   (#("--" 0 2
      (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
    global-mode-string))
  #("-%-" 0 3
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0")))

You could clean this up to be a lot clearer.  Part of it is the pretty 
printer is doing an awful job, part of it is the explicit propertized 
strings.  Imagine if it was like this:

(mode-line-mem-info
  (:propertize "-" (mode-line-default-props))
  mode-line-mule-info
  mode-line-modified
  mode-line-frame-identification
  (:propertize "    " (mode-line-default-props))
  mode-line-position
  mode-line-vc-info
  mode-line-modes
  mode-line-which-func-info
  global-mode-string
  (:propertize "-%-" (mode-line-default-props)))

And then you could expose this in Customize as a reorder-able list!

In short, I have four proposals:

1. Change mode-line-format to not include ANY explicitly propertized 
strings.  Use :eval and :propertize.
2. Remove condition branching in mode-line-format.  Just variables with 
formatting info should be there, put the branching in those variables.
3. Change the pretty-printer used by C-h v to somehow recognize that 
mode-line-format should be formatted with a newline after every element.
4. Change the customize option for mode-line-format to display it as a 
reorderable list, like c-mode-hook.

   -- MJF

Re: Customizing the mode line

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I do not follow: which problem is this supposed to help with,
> and how?

It makes it easier to users to figure out how to re-order the mode-line.
As Jared Finder just posted in another sub-thread:

> Reordering the mode line is much harder (and would be greatly
> appreciated by me).  I think if you cleaned up mode-line-format so
> that it only included VARIABLES, then this would be clear as day.
> Right now mode-line-format's default value is big and scary

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 14:07:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I do not follow: which problem is this supposed to help with,
> > and how?
> 
> It makes it easier to users to figure out how to re-order the mode-line.

Yes, that would help.  Thanks.  But the variables need to be options,
so that "M-x set-variable RET" completes on them.  Having to use setq
automatically means users who are not Lisp programmers will have
difficulties.

Re: Customizing the mode line

[Eli Zaretskii]

> From: M Jared Finder <jared@hpalace.com>
> Date: Sat, 31 Oct 2009 10:46:23 -0700
> 
> Eli Zaretskii wrote:
> >> From: Richard Stallman <rms@gnu.org>
> >> CC: emacs-devel@gnu.org
> >> Date: Sat, 31 Oct 2009 07:07:44 -0400
> >>
> >> I don't think that a better UI for customizing the mode line is a
> >> really important place to improve.  Customizing it is not that hard to
> >> do.
> > 
> > ??? Really?  Then please describe how to do that.  What user options
> > are available for that, and what values one should give them for the
> > following use-cases:
> 
> The first two are easy.

Not really.

> >  . Show only the major mode, not the minor modes.
> 
> (setq minor-mode-alist nil)

"C-h v minor-mode-alist RET" produces a 100-odd line long "*Help*"
buffer, where even I get lost.  And how did you know that setting it
to nil will do the trick? the doc string doesn't tell.

> or customize mode-line-modes

This one produces a 123-line "*Help*" buffer.  Most users will not
know how even to start customizing it, because the various portions of
the spec are not documented at all.

> >  . Remove the percent/All/Top/Bot part.
> 
> Remove the first two entries of mode-line-position

Come on! "C-h v" on this variable produces a 71-line "*Help*" buffer
for just 3 indicators.  If this is user-friendly UI, then I don't know
what a user-friendly UI is.

> In short, I have four proposals:
> 
> 1. Change mode-line-format to not include ANY explicitly propertized 
> strings.  Use :eval and :propertize.
> 2. Remove condition branching in mode-line-format.  Just variables with 
> formatting info should be there, put the branching in those variables.
> 3. Change the pretty-printer used by C-h v to somehow recognize that 
> mode-line-format should be formatted with a newline after every element.
> 4. Change the customize option for mode-line-format to display it as a 
> reorderable list, like c-mode-hook.

Sounds like a good plan.  Thanks.

Re: Customizing the mode line

[Juanma Barranquero]

On Sat, Oct 31, 2009 at 15:09, Robert J. Chassell <bob@gnu.org> wrote:

> I have the following in my .emacs file and am not as good a programmer as
> Eli Zaretski:
>
>  (setq default-mode-line-format
...
>    )))

I hope that's not an example of how easy is customizing the mode line.

    Juanma

Re: Customizing the mode line

[Juanma Barranquero]

On Sat, Oct 31, 2009 at 18:46, M Jared Finder <jared@hpalace.com> wrote:

> 1. Change mode-line-format to not include ANY explicitly propertized
> strings.  Use :eval and :propertize.
> 2. Remove condition branching in mode-line-format.  Just variables with
> formatting info should be there, put the branching in those variables.
> 3. Change the pretty-printer used by C-h v to somehow recognize that
> mode-line-format should be formatted with a newline after every element.
> 4. Change the customize option for mode-line-format to display it as a
> reorderable list, like c-mode-hook.

These are really good suggestions. 1 and 2 would go a long way towards
reducing the current pain.

    Juanma

Scrollbar thumbs (was: Customizing the mode line)

[Stefan Monnier]

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

It does with some GUI and not with others.  In principle it should.
The only reason for it not to is to try and work around problems when
dragging the scrollbar thumb, where many GUI toolkits are absurdly
dogmatic and make it pretty much impossible for Emacs to do what
it should.

The more I see it, the more I think that rather than let the GUI code
make this choice, we should have it be in the generic part of the code
and the GUI code only chooses the default value, so users can choose to
have a half-working drag-scroll if they prefer it (because it gives them
proper display of the thumb size and position in return).


        Stefan

Re: Customizing the mode line

[Robert J. Chassell]

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customizing the mode line

[Robert J. Chassell]

        > I have the following in my .emacs file

    That's just a copy of what bindings.el has, with some changes.

Yes!  That is why it is a simpler user command than one such as
customize-* which has more than a dozen completions.

    ... set for when I want to change the mode-line appearance temporarily.

I cannot help you.  Changing the value in a setq is the quickest method
that I know and requires the least learning.  Fortunately, writing a
.emacs file (mostly by copying, of course) is less complicated than
reading, which almost every child learns (in a developed country).
Emacs takes some learning, like all else.  Doubtless, anything that we
can learn and become accustomed to, even `customize-*', can become
`intuitive'.  But I lack the ability to learn anything complicated.  So
I stick to .emacs files.  (I am not as good as I was.)
-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Scrollbar thumbs

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>         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.
>
> It does with some GUI and not with others.  In principle it should.
> The only reason for it not to is to try and work around problems when
> dragging the scrollbar thumb, where many GUI toolkits are absurdly
> dogmatic and make it pretty much impossible for Emacs to do what
> it should.

Is it only GTK which is brain-damaged in this area?  Do other toolkits
do the same thing?

-Miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: Customizing the mode line

[Eli Zaretskii]

> From: bob@gnu.org (Robert J. Chassell)
> Date: Sat, 31 Oct 2009 22:40:49 +0000
> 
>     ... set for when I want to change the mode-line appearance temporarily.
> 
> I cannot help you.  Changing the value in a setq is the quickest method
> that I know and requires the least learning.  Fortunately, writing a
> .emacs file (mostly by copying, of course) is less complicated than
> reading, which almost every child learns (in a developed country).
> Emacs takes some learning, like all else.  Doubtless, anything that we
> can learn and become accustomed to, even `customize-*', can become
> `intuitive'.  But I lack the ability to learn anything complicated.  So
> I stick to .emacs files.  (I am not as good as I was.)

"M-x set-variable RET" is not complicated.

Re: Customizing the mode line

[Richard Stallman]

The basic way to customize the mode line is by setting the variables
that control it.  It is not terribly hard.

The more important issue is that helping users customize the mode line
is not vitally important, as things go.  If we made customizing the
mode line much easier, Emacs would not be significantly more useful as
a result.

Let's do the things that really make Emacs more useful.

For instance, a lot of work has been done on MuMaMo.  Perhaps we
should get that installed now.  Or perhaps we should use one of the
other programs that do this job, or a combination.

Re: Customizing the mode line

[Juanma Barranquero]

On Sun, Nov 1, 2009 at 10:28, Richard Stallman <rms@gnu.org> wrote:

> The more important issue is that helping users customize the mode line
> is not vitally important, as things go.  If we made customizing the
> mode line much easier, Emacs would not be significantly more useful as
> a result.
>
> Let's do the things that really make Emacs more useful.

By that simplistic priority scheme, we should not waste any time
fixing typos either.

> For instance, a lot of work has been done on MuMaMo.  Perhaps we
> should get that installed now.  Or perhaps we should use one of the
> other programs that do this job, or a combination.

That's a false dichotomy. Installing MuMaMo does not preclude working
on the modeline issue, or vice versa.

    Juanma

Re: Scrollbar thumbs

[Stefan Monnier]

> Is it only GTK which is brain-damaged in this area?  Do other toolkits
> do the same thing?

Yes, IIUC w32 does the same (and Xaw3d as well, tho to a lesser extent).


        Stefan

Re: Scrollbar thumbs

[Jason Rumney]

Stefan Monnier wrote:
>> Is it only GTK which is brain-damaged in this area?  Do other toolkits
>> do the same thing?
>>     
>
> Yes, IIUC w32 does the same (and Xaw3d as well, tho to a lesser extent).
>   

Since 23.1, Emacs on w32 allows the scroll thumb to shrink while being 
dragged at the bottom of the buffer.  Previous versions fixed the size 
of the thumb while dragging, which I think is the brain damage which GTK 
forces on you that Miles is refering to, as you are unable to reach the 
bottom of the buffer by dragging the scrollbar in some circumstances 
because of assumptions Emacs makes to relate characters to pages of 
scrolling without wasting time doing a full calculation over the buffer.

Re: Scrollbar thumbs

[Stefan Monnier]

> Since 23.1, Emacs on w32 allows the scroll thumb to shrink while being
> dragged at the bottom of the buffer.  Previous versions fixed the size of
> the thumb while dragging, which I think is the brain damage which GTK forces
> on you that Miles is refering to, as you are unable to reach the bottom of
> the buffer by dragging the scrollbar in some circumstances because of
> assumptions Emacs makes to relate characters to pages of scrolling without
> wasting time doing a full calculation over the buffer.

Not sure how it works on w32, but yes on Gtk IIRC the thumb can't be
resized during dragging.  In Xaw3d the problem was halfway: the code
was/is able to resize the thumb during a drag, but the thumb may hit the
bottom too soon, in case we haven't resized it quickly enough.

My favorite solution to those problem nowadays is to set the thumb-size
to its minimum (typically 0, which results in a small but no invisible
thumb) during dragging: makes for smooth scrolling (without the need to
resize the thumb during scrolling) while still allowing the thumb size
to correctly reflect the begin&end of the viewed area when
not scrolling.


        Stefan

Re: Customizing the mode line

[Evil Boris]

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

I am sure usages vary, but with every new "improvement" in GUIness of
Emacs I modify my .emacs to turn the feature off.  No menu bar.  No
scroll bars.  No tool bar.  Thank you.  Please keep the percentage of
the buffer around, or make it easy to put back in if you do not.