[Top][All Lists]

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

Re: address@hidden: Re: Emacs 20.0.91 pretest available]

From: Olivier Lecarme
Subject: Re: address@hidden: Re: Emacs 20.0.91 pretest available]
Date: Wed, 29 Nov 2006 08:56:26 +0100

Bill Wohler <address@hidden> wrote:

> Olivier Lecarme <address@hidden> wrote:
> > I'm using [Emacs 22] on a daily basis on all these machines, and did not yet
> > encounter any problem. My only remark, for the present, is that in MH-E
> > folder mode, the icon showing mail available is so far on the right that
> > it cannot be seen in a normal window (if the date and time are shown in
> > the mode line). This was not the case in the previous version.
> Hi Olivier!

Hi Bill!

> Richard had originally contacted me and I responded to him as follows:
> Bill Wohler <address@hidden> wrote:
> > This is actually something I've noticed as well. This is not due to a
> > change in MH-E--we've only added a logo which added 2 characters. The
> > big change is the reorganization of the mode line between Emacs 21 and
> > 22: the file location information such as "All L12", which was
> > previously on the right, was swapped with the time, load average, and
> > mail indicator. Instead of being in the middle, the mail indicator is
> > now on the far right and is often cut off, and not only in MH-E buffers.
> > 
> > To fix this, I'd suggest removing some space around the file location so
> > that there is always just two spaces on either side of it. There is
> > currently three spaces before it, and up to five spaces after it. The
> > first three can certainly be two; I understand that the remaining space
> > is there to keep the mode line from flickering as you move around the
> > file, but I think the redrawing of the mode line is less of a problem
> > than the loss of information.
> While removing the extra space will help, upon further reflection, I
> have a feeling that we (the MH-E team) will have to clean up the
> mode-line some. I'm widening the distribution to get some feedback and
> suggestions.
> For example, I'm looking at the following mode line:
> 1:%%  XX  {+outbox/select} 60 msgs (15266-15325)   Bot L60    (MH-Folder Show 
> MC
> Note how with a lot of messages, the mode-line real estate is chewed up.
> Here's another example:
> 1:%%  XX  {+mhe-index/foo_and_bar__and_baz} no msgs   All L1     (MH-Folder 
> MC-r
> So, long folder names will chew up real estate too.

In my case, here is the mode line I'm looking at:

-1:%* XX  (+inbox) 39 msgs (1-50)   Top L32     (MH-Folder Show)----mer 29 nov 
08:21 0.50------------

Of course I had to make the window wider in order to see all the
informations, otherwise it ends just before the system load. Of course I
could remove the date, time and system load, but I would lose the mail
indicator as well... Anyway, there are a lot of spaces which could be
compressed, as well as the dashes:

-1:%* XX (+inbox) 39 msgs (1-50) Top L32 (MH-Folder Show)-mer 29 nov 08:21 

Since the mode line has a length greater than the window width, because
of the fringes and the scroll-bar, this would probably leave room for
the mail indicator, but only in the case of short folder names, few
messages, and no additional minor mode. At least it would be useful.

> Here are a couple of ideas:

A large couple indeed!

> 1. Remove the number of messages in the MH-Folder mode line. In the
>    example above, the "60 msgs" text is usually redundant and can be
>    largely inferred (if there aren't many holes) from the range of
>    messages.

This is not always completely redundant, as demonstrated by my example,
but this information is not crucial.

> 2. Remove the number of messages and the range of messages from the mode
>    line (for example, "60 msgs (15266-15325)" above) since you can
>    easily get that information by looking at the first message and last
>    message in the buffer.

Same remark: not redundant, but not crucial, and easily available.

> 3. Remove the /select from the folder name (which shows that we're only
>    looking at a part of a folder--see
>    mh-partial-folder-mode-line-annotation). Alternatively, setting
>    mh-partial-folder-mode-line-annotation to a single character such as
>    `-' might enough to show that you'd only looking at a subset of a
>    folder.

Certainly: the word "select" is too big anyway.

> 4. Use a variant of the Gnus newsgroup abbreviation if the folder name
>    is longer than a certain threshold. For example, gmane.emacs.devel is
>    g.e.devel. Would we use a similar heuristic?

This would be a good idea, especially if one uses more than two levels
of folders.

> 5. Truncate folder names to 20 characters.

I would not imagine using folder names longer than a few letters: I have
been a user of MH and MH-E when there was no completion available!
Anyway, if you mean the complete folder path, the preceding idea (#4) is
a better idea, in my opinion.

> If you're an MH-E user, are any of these ideas repugnant to you? Do any
> appeal to you? If you're an Emacs/Gnus developer, can you suggest best
> practices for the mode line that our users can evaluate?

I'm a MH-E user, and I use it in two different ways : in a windowed
Emacs, with its fringes and scroll-bar, which enlarge the mode line,
but also in a textual Emacs, on a distant computer accessed via an Xterm
and a Screen. In this second case, real estate in the mode line is
strictly limited to the width of the Xterm window, which itself is
limited by the size of my screen and the existence of other windows.

None of the preceding ideas is repugnant to me. The best solution, if
feasible, would be to apply these various heuristics in succession, as
necessary: if there is room enough, no compression at all, and then try
to squeeze more and more, in order that the mail indicator remains
always visible. I'm not sure if there would be enough information
available from within Emacs in order to do this.

> Thanks!

You're welcome!

> -- 
> Bill Wohler <address@hidden>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD


                        Olivier Lecarme

reply via email to

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