v2a20 formatting and date problems

From: Tom von Alten <tom_vonalten_at_boi.hp.com_at_hypermail-project.org>
Date: Thu, 13 May 1999 17:40:34 -0600
Message-ID: <001701be9d99$ff9da070$c9d1020f_at_alien-nt.boi.hp.com>


Greetings:

I'm testing v2a20 (unpatched, downloaded 7 May) on my hp-ux 10.20 system. I have an email alias set to pipe into hypermail via stdin, with all but the
-i option set in a -c option file.

I'm seeing three problems:

  1. hm_showhtml produces an unreadably misformatted message
  2. date/thread indexes are not properly ordered. Messages arriving close together with hypermail in single message update mode result in misordering which sometimes gets fixed by new messages coming in, and sometimes gets worse with new messages coming in.
  3. I'd prefer a consistent, local format for the date string in the index pages. Parseing the date out of messages coming from multiple locations and multiple MUAs creates a confusing mess.

More detail on each of these follows.

  1. The [hm_showhtml = 0] setting, with at least one email header being printed (To: in my case, but I don't suppose it matters), is NOT wrapping <pre> around the body: the header has it, but then it's turned off, and the body is turned into one big <P>. Not a pretty sight!

On line 451 of print.c, we've reached the end of the headers we're going to show, and the following code seems to get executed:

  if(pre /*set_showhtml && set_showheaders && pre*/) {     fprintf(fp, "</PRE>\n");
    pre=FALSE;
  }
  fprintf(fp, "<P>\n");

It appears that the test should be
  if(set_showhtml && pre) {
rather than just (pre). Or maybe just (set_showhtml).

I tried it out with just (set_showhtml) and the message looks right, but it ends up with a <P> in the <pre> block that doesn't belong there:
<!-- body="start" -->
<PRE>

  To: <A HREF="mailto:(stuff)">arctest_at_xyz.hp.com</A>

<P>

  This message has three paragraphs.

  This is the second ppg.

  This is the third.
</PRE>
<P><!-- body="end" -->

I'm guessing someone more familiar with the current print.c can find that and fix it more quickly than I.

2. The date and thread indexes seem to be prone to disturbance by having multiple messages arrive in close proximity. I'm sending several messages from another system, using mailx commands on a command line, like   echo "body"|mailx -s "#1" addr; echo "body"|mailx -s "#2" addr

In one test with six such messages, the most recent one was sent to the wrong end of the list:

  18:18:29 Msg #5
  18:18:28 Msg #4
  18:18:27 Msg #3
  18:18:25 Msg #2
  18:18:24 Msg #1
  18:18:30 Msg #6

I sent a new message, and the order righted itself! Msg 7,6,...1.

Two more messages made the order go to 8,7,9,6..1 And another made it 9,8,7,10,6..1
So 7-9 have been straightened out, but 10 is out of order. Another message, and the order is 9,8,7,10,11,6..1

Very strange, and a hard to explain pattern from my end.

3. The date that shows in the indexes is what's parsed out of the sender's email. Perhaps this got debated and settled earlier? While it's nice to see the order things were sent in, having timezones from around the world showing up can make it pretty confusing (especially with the unreliability described in item 2).

I think it makes more sense to use the archiving system's date, formatted in as terse a format as possible; for example, date -u +"%e %b %Y %H:%M:%S" This allows easy comparison, should be reliably parseable out of the message header, and minimizes the index page space required because TZ and/or GMT offsets are not needed.

The "show_header" option including "Date" should provide the means to preserve the sender's "Date:" field, if that's specifically desired. But not in the index, where it can do more harm than good!

Cheers,
_____________ Hewlett-Packard Computer Peripherals Bristol Tom von Alten mailto:Tom_vonAlten_at_boi.hp.com

          This posting is for informational purposes only.
          It is not a statement of the Hewlett-Packard Co.
Received on Fri 14 May 1999 02:03:50 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT