Re: Feature request

[Earl Hood <earl@xxxxxxxxxxxx>]

On December 18, 2005 at 00:11, Ken Bass wrote:

> 1) Add a '-verbose' option which prints the filename before processing 
> it. Currently whenever warnings are printed (such as unable to parse 
> date) there is no way to tell which file caused the problem when 
> processing a folder.
> 
> This change is pretty easy. I modified mhamain.pl line 345 to print 
> $mesgfile instead of a '.'.

-verbose is the default.  You want a "more verbose" mode, like a
debug mode that is more verbose, which I have considered in the
past, but have not bothered to do the work for.

Printing the filename only makes since for MH-style input, so your
patch is unique to your input.  As of now, the message-id is printed,
allowing one to grep for the actual message, regardless of input.

> 2) Add a resource that contains the 'input' filename. Basically, I would 
> like there to be a mapping between the generated data and the input 
> file. I am thinking MHonarc should add something like:
> <!--X-Input-Filename: /var/archive/mbox/file1.txt -->

This his has been discussed in the past.  The input filename is
not always known, and it varies based on the style of input: mbox
or mh.  What does exist are callbacks (see the API appendix and
$mhonarc::CBMessageConverted) that provides hooks.  The callbacks
were added due to a request by a user.

> When converting large archives, sometimes there are errors in the 
> processing and at least by examining the HTML source you could see
> which input file causes it. The message ID is not always useful, 
> especially when MHonarch generate its own id.

Agree on the last part.  If you are processing news spools, why
are there no message-ids?

A problem with tracking the filename is it increases the amount of
data stored in the dbfile.  The callback API could be used to track
the info for those interested.  Alternatively, mhonarc could be
modified to have diagnostic data in message pages that are preserved
during edits so the info is not lost (which would require a new
deliminting token to preserve such info).

Of course, if such changes were made, the feature would be optional
since revealing such information could be a security concern for
users.

--ewh