Comment 2 for bug 740755

I had seen it with previous revisions, though now I am not sure which
ones they were (I seem to remember maybe back at 8.1.92a). The only
reason for 1013 was that I had downloaded just to get the latest
development code. A quick grepping of the VM tree doesn't reveal
anything obvious, in fact there are very few places that vm uses the
mime-layout setting functions, which makes me more suspicious that it
is a markers issue. I wonder if in the mean time, it would be useful
to have a 'vm-mime-layout-use-cache' or such variable that, if set to
nil, could help sort out if its a performance killer.

-Arik

On Thu, Mar 24, 2011 at 5:13 AM, Uday Reddy <email address hidden> wrote:
> Roger.  I understand, though I haven't seen any instances of this
> myself.  It is a nasty bug!
>
> Did you try it with different rvisions of VM?  Why revision 1013?
>
> Cheers,
> Uday
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/740755
>
> Title:
>  mime-layout part markers get mangled
>
> Status in VM (View Mail) for Emacs:
>  New
>
> Bug description:
>  [VM development version at revision 1013]
>
>  After deleting and expunging (maybe) and (perhaps) saving, it seems
>  the markers that indicate buffer locations of mime parts all get set
>  to the same value (at about the start/end of the body or so) and thus
>  when decoding end up with no text in the presentation for any given
>  mime part.
>
>  The markers for the body start/end of the message in message-pointer
>  are still valid, and I can counteract the behavior by
>
>  (with-current-buffer "inbox" (vm-set-mime-layout-of (car vm-message-
>  pointer) (vm-mime-parse-entity-safe (car vm-message-pointer)))
>
>  This works since normally when previewing a message the layout is
>  retrieved from cache, and in the code above the parts are re-parsed
>  for their positions.
>
>  This bug is quite hard to track down since it doesn't always occur on
>  a delete/expunge. It may also be a bug in the handling of markers
>  after modifying the length of the buffer through deletes, and thus not
>  a VM issue, though I am suspicious because the markers for the message
>  itself are not affected and thus handled correctly. I have not yet
>  tested this with a emacs -q, perhaps others have seen this behavior.
>
>  An obvious solution is simply to freshly parse the mime parts
>  locations each time a message is previewed instead of caching this
>  information, but perhaps the caching is important for larger mails and
>  thus desirable (it takes essentially no time on my machine to do the
>  parsing for any emails I have tried).
>
>  And lastly, I have experienced this behavior both on an intel Mac osx
>  10.6 and a centos linux box.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/vm/+bug/740755/+subscribe
>