Gnus development mailing list
 help / color / mirror / Atom feed
* Re: [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available]
       [not found] <E1GpG8I-00085V-P5@fencepost.gnu.org>
@ 2006-11-29  5:18 ` Bill Wohler
  2006-11-29  7:56   ` Olivier Lecarme
  2006-11-30  3:20   ` Richard Stallman
  0 siblings, 2 replies; 4+ messages in thread
From: Bill Wohler @ 2006-11-29  5:18 UTC (permalink / raw)
  Cc: mh-e-users, ding, emacs-devel

Olivier Lecarme <ol@i3s.unice.fr> 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!

Richard had originally contacted me and I responded to him as follows:

Bill Wohler <wohler@newt.com> 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.

Here are a couple of ideas:

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.

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.

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.

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?

5. Truncate folder names to 20 characters.

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?

Thanks!

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available]
  2006-11-29  5:18 ` [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available] Bill Wohler
@ 2006-11-29  7:56   ` Olivier Lecarme
  2006-11-30  3:20   ` Richard Stallman
  1 sibling, 0 replies; 4+ messages in thread
From: Olivier Lecarme @ 2006-11-29  7:56 UTC (permalink / raw)


Bill Wohler <wohler@newt.com> wrote:

> Olivier Lecarme <ol@i3s.unice.fr> 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 <wohler@newt.com> 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 0.50------------

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 <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

-- 


			Olivier Lecarme



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available]
  2006-11-29  5:18 ` [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available] Bill Wohler
  2006-11-29  7:56   ` Olivier Lecarme
@ 2006-11-30  3:20   ` Richard Stallman
  2006-11-30  7:05     ` Bill Wohler
  1 sibling, 1 reply; 4+ messages in thread
From: Richard Stallman @ 2006-11-30  3:20 UTC (permalink / raw)
  Cc: emacs-devel, mh-e-users, ding, ol

Another option is that MH-E could remove the buffer position
indicators ("All L60") from the mode line.
MH-E is not required to keep all the normal mode line fields.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available]
  2006-11-30  3:20   ` Richard Stallman
@ 2006-11-30  7:05     ` Bill Wohler
  0 siblings, 0 replies; 4+ messages in thread
From: Bill Wohler @ 2006-11-30  7:05 UTC (permalink / raw)
  Cc: mh-e-users, ol, ding, emacs-devel

Richard Stallman <rms@gnu.org> wrote:

> Another option is that MH-E could remove the buffer position
> indicators ("All L60") from the mode line.
> MH-E is not required to keep all the normal mode line fields.

Thank you. The line number isn't relevant in MH-E folder buffers. The
percentage might still be desired by our users.

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-11-30  7:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E1GpG8I-00085V-P5@fencepost.gnu.org>
2006-11-29  5:18 ` [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available] Bill Wohler
2006-11-29  7:56   ` Olivier Lecarme
2006-11-30  3:20   ` Richard Stallman
2006-11-30  7:05     ` Bill Wohler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).