understanding code.c(_mutt_copy_message) ->v?size calculation

[Rado S <list-rado@xxxxxx>]

Moinsen,

while searching for a solution to make %l and %L in status_format
match for IMAP folders when you use '..' to limit to 'ALL' entries
(they differ for IMAP unlike for local mbox folders), I noticed
these occurances for "->vsize":

------ QUOTE BEGIN ------
copy.c:
        Context->size   -= body->length - new_length;
        Context->vsize  -= body->length - new_length;
curs_main.c:
        ctx->vsize      +=THIS_BODY->length     + THIS_BODY->offset     - 
THIS_BODY->hdr_offset;
mx.c:
        ctx->vsize      +=this_body->length     + this_body->offset     - 
this_body->hdr_offset;
pattern.c:
        Context->vsize  +=THIS_BODY->length     + THIS_BODY->offset     - 
THIS_BODY->hdr_offset;
thread.c:
        ctx->vsize      +=cur->content->length  + cur->content->offset  - 
cur->content->hdr_offset;
------- QUOTE END -------

My original solution was to drop in imap/message.c the subtraction
of the fetched headers' size by this:

------ QUOTE BEGIN ------
        h->content_length -= bytes;
------- QUOTE END -------

This means: count only the body, without the fetched headers
("bytes"). This is plain wrong, since as you can see above, %L
("vsize") includes the headers, too.

Dropping the subtraction wouldn't be the perfect solution either:
 %l could never match %L exactly, because that IMAP fetched headers
("bytes") doesn't have _full_ headers (just a subset of those needed
to work) as used in the vsize calculations given above.

Even %c in index_format only shows the body length without header,
so it all would become more consitent if we could drop adding the
header to vsize everywhere (and keep the "bytes" adjustment to get
the pure body size for IMAP).

So far I've failed to understand in copy.c where the header size
comes into play with "new_length" to get rid of it! Its value is
modified in "count_delete_lines", but I lack the details (like
what's the "84" for, or why "dellines-=3;").
 If I know what happens there, then I could make %l + %L match _and_
make those vsize functions faster by dropping all the extra
calculations to include the header size at those other places.

Is "size + vsize" calculation in copy.c needed at all?
Once the folder is updated, isn't it reread again and therefore the
"size" calculated from the total again?

Clues welcome.

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.