🚀 go-pugleaf

Jamie Zawinski writes:

> You're right, that was the problem.  Building a digest didn't do it for
> me, but after doing
> 
>   (let ((rest vm-message-list))
>     (while rest
>      (vm-stuff-attributes (car rest))
>      (setq rest (cdr rest))))
> 
> computing the summary buffer only took about twelve seconds.  But parsing the
> message-lists still took the same amount of time as before.  

I believe that is because a magic header full of empty fields is useless
   or worse.

> All the messages that were in that folder got there by this path: arriving 
> in my inbox; having a summary generated for them; and then being copied with
> vm-save-message.  I had assumed that this sequence of events would cause a
> fully computed X-VM-v5-Data header to be saved, but the one that was saved
> was mostly empty (none of the date/time fields filled in, for example.)

By empty, do you mean the fields were nil or they were "" ?
As I understand it, nil means to ignore the header for that field,
but "" means don't even bother looking in the message.
That is what I mean by "useless or worse".

> I think that before outputting a message to a file, the X-VM-v5-Data header
> should be fully computed, so that a little extra time is spent at save-time
> instead of potentially a lot of time later.
> 
> Actually, I'd be perfectly happy having the magic header fully computed as
> soon as a message arrives in my inbox.  

That's all very nice, but the first thing to do is to get them to properly
reflect the information available in the message.  This is one of the 
aspects of my ongoing problem which is the subject of the separate thread
entitled "Incomplete X-VM-v5-Data headers" .

I have managed to spend a little time with this and looked at the
regexps in the function 'vm-su-do-date .  The one for ctime(3) looks a
little suspicious to me since some date formats put the timezone
before the year.  My fiddling with this didn't seem to help, but it
still might be in the ballpark.

Please post here if anyone has any insights about all this.

- Len Weisberg - HP Corp Computing & Services - weisberg@corp.hp.com