Re: MHonArc v2.0 alpha Available

1996-09-16 17:52:50
Earl Hood said:
Some of you have shown interest in trying out v2.0, so I have
made a tar bundle available at

Remember, this is an alpha version.  The documentation has NOT
been updated yet.  The only documentation on the new features is
in the CHANGES file.  Hence, you are on your own.  I suggest grabbing
the sample resource file from the v2.0 demo,
<URL:> to get a
good idea on how to utilize some of the new features.

All feedback is welcome.

Here it is :-)

- The alorithm used in the followup and refs section of a message
  does not use the same (new) algorithm used as for the thread index.
  Only 'true' followup & refs are used not the 'possible' ones.
  Both lists should list the same messages IMHO regardless what
  algorithm used.

- -modtime is the default. That's okay for me (thanks for the feature)
  but maybe -nomodtime is a better default. Netscape cache is a real
  pain when making test with -modtime :-)

- It may be convinient to have a switch that makes the TopPNI and
  BotPNI section of a message the same, e.g., to use the same 'button'
  row at the top and buttom.

- To save some bytes in .mhonarc.db one can remove the whitespace
  between key value pairs (patch below). Same could be done for
  %From values in .mhonarc.db, they all have
  a trailing blank.

- require of filters on demand. Most mails I process here are not

- Message date: For big mailing lists I often get mail out of time
  order. Suggestion: first use 'Date:' and if date convertions
  fails use first date 'Received:' header.

- -multipg switch: mhonarc -outdir test -multipg  test.mbox
  results in:

Writing mail .Illegal division by zero at /local/mail/2.0a1/lib/ 
line 127

  -multipg should only be allowed if -idxsize (or corresponding env or
  resource is specified)

  multipage index is a great, great feature.

- main/thread index button in messages always refer to indexname#msgnum
  This is no longer always true if multipage is used.

- -reverse and multipage links. If you add a message to such an archive
  all mail*.html thrd*.html files have to be rewriten. I would not mind
  if the maillist.html and thread.html would contain betwwen 1-IDXSIZE
  msgs.  So only these 2 files need to be updated (plus 2 other if
  the total msg number requires another index file).

- [First Page], [Last Page] links in multiple index pages would useful.

- Have not checked it but: Is a thread always completely included in
  one thrd*.html page (even if IDXSIZE is exceeded)? Seems to be
  meaningful (whatever that is :-).

It's just fun to play with the new features.

Great work,

---     1996/09/16 22:11:01     1.1
+++     1996/09/16 22:47:17
@@ -164,9 +164,9 @@
 sub print_assoc {
     local($handle, $name, *assoc) = @_;
-    print $handle "%$name = (\n";
+    print $handle "%$name=(\n";
     foreach (keys %assoc) {
-       print $handle qq{'}, &escape_str($_), qq{', '},
+       print $handle qq{'}, &escape_str($_), qq{','},
                      &escape_str($assoc{$_}), qq{',\n};
     print $handle ");\n";
@@ -175,7 +175,7 @@
 sub print_array {
     local($handle, $name, *array) = @_;
-    print $handle "\(_at_)$name = (\n";
+    print $handle "\(_at_)$name=(\n";
     foreach (@array) {
        print $handle qq{'}, &escape_str($_), qq{',\n};
@@ -185,7 +185,7 @@
 sub print_var {
     local($handle, $name, *var, $d) = @_;
-    print $handle qq{\$$name = '}, &escape_str($var), qq{'};
+    print $handle qq{\$$name='}, &escape_str($var), qq{'};
     print $handle qq{  unless defined(\$$name)}  if $d;
     print $handle qq{;\n};

<Prev in Thread] Current Thread [Next in Thread>