From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Olivier Lecarme Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel,gmane.mail.mh-e.user Subject: Re: [ol@i3s.unice.fr: Re: Emacs 20.0.91 pretest available] Date: Wed, 29 Nov 2006 08:56:26 +0100 Message-ID: <6708.1164786986@pierredelune.i3s.unice.fr> References: <15629.1164777488@olgas.newt.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1164815453 5547 80.91.229.2 (29 Nov 2006 15:50:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Nov 2006 15:50:53 +0000 (UTC) Original-X-From: ding-owner+M12554@lists.math.uh.edu Wed Nov 29 16:50:50 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GpRhN-0005yU-5m for ding-account@gmane.org; Wed, 29 Nov 2006 16:50:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1GpRep-000425-96; Wed, 29 Nov 2006 09:47:35 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1GpKJ5-0000ku-J3 for ding@lists.math.uh.edu; Wed, 29 Nov 2006 01:56:39 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.63) (envelope-from ) id 1GpKIy-0000ov-Vw for ding@lists.math.uh.edu; Wed, 29 Nov 2006 01:56:39 -0600 Original-Received: from [134.59.130.1] (helo=smtp.i3s.unice.fr) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1GpKIx-0002QN-00 for ; Wed, 29 Nov 2006 08:56:31 +0100 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.i3s.unice.fr (Postfix) with ESMTP id 74EB13F6E4; Wed, 29 Nov 2006 08:56:28 +0100 (CET) X-Virus-Scanned: amavisd-new at i3s.unice.fr Original-Received: from smtp.i3s.unice.fr ([127.0.0.1]) by localhost (smtp.i3s.unice.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC6X+5Lm3DAd; Wed, 29 Nov 2006 08:56:26 +0100 (CET) Original-Received: from pierredelune.i3s.unice.fr (pierredelune.i3s.unice.fr [134.59.133.64]) by smtp.i3s.unice.fr (Postfix) with ESMTP id EA4D23F6E3; Wed, 29 Nov 2006 08:56:26 +0100 (CET) Original-Received: from ol (helo=pierredelune.i3s.unice.fr) by pierredelune.i3s.unice.fr with local-esmtp (Exim 4.63) (envelope-from ) id 1GpKIs-0001kD-Sy; Wed, 29 Nov 2006 08:56:26 +0100 Original-To: emacs-devel@gnu.org, mh-e-users@lists.sourceforge.net, ding@gnus.org, Olivier Lecarme In-reply-to: <15629.1164777488@olgas.newt.com> Comments: In-reply-to Bill Wohler message dated "Tue, 28 Nov 2006 21:18:08 -0800." X-Mailer: MH-E 8.0.3; nmh 1.2; GNU Emacs 22.0.91 X-Image-URL: http://pierredelune.i3s.unice.fr/usr/OL-2004.jpg X-Spam-Score: -2.1 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:64032 gmane.emacs.devel:63031 gmane.mail.mh-e.user:1716 Archived-At: Bill Wohler wrote: > Olivier Lecarme 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 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 http://www.newt.com/wohler/ GnuPG ID:610BD9AD -- Olivier Lecarme