[VM] Old bug in "vm-8.2.0b"

[Dr Rainer Woitok]

Uday,

there's another bug molesting me since I upgraded from "vm-7.17" or so
to "vm-8.1.1", and this bug is still present in "vm-8.2.0b", too:

Writing a mail and attaching a PDF document to it looks nice, the grey
button line denoting the attachment starts with a cute paper clip to the
left followed by a textual description of the attachment in square
brackets.

After sending off the mail it is stored in my inbox, and there the grey
button line denoting the attachment looks sort of ugly: the cute paper
clip is missing altogether, and the textual description says
"[Unknown/Bad PNG image encoding]PDF: <file name>, [display]".

Back when I was still using "vm-8.1.1" I did a lot of googling and found
several other people having the same complaints. I even found a comment
by you, dated 2011-02-04 and sugesting this having to do with coding
systems. You even offered the following patch then (even though not in
the "git" format used by me below):

--- vm-mime.el.~1~ 2010-04-25 15:34:20.000000000 +0200
+++ vm-mime.el 2013-05-10 11:38:57.775000000 +0200
@@ -3850,11 +3850,13 @@
(save-excursion
(setq work-buffer (vm-make-work-buffer))
(set-buffer work-buffer)
+ (set-buffer-file-coding-system (vm-binary-coding-system))
;; convert just the first page "[0]" and enforce PNG output by "png:"
- (setq success
- (eq 0 (apply 'call-process vm-imagemagick-convert-program
- tempfile t nil
- (append convert-args (list "-[0]" "png:-")))))
+ (let ((coding-system-for-read (vm-binary-coding-system)))
+ (setq success
+ (eq 0 (apply 'call-process vm-imagemagick-convert-program
+ tempfile t nil
+ (append convert-args (list "-[0]" "png:-"))))))
(if success
(progn
(write-region (point-min) (point-max) tempfile nil 0)

To cut a long story short, this patch, even though it was applicable to
"vm-8.1.1", did then not solve the problem (but it didn't hurt either,
so I left it in there). However, instead of trying to transfer this
non-working patch to "vm-8.2.0b" I spent a few days ploughing through
the "vm-8.2.0b" source code and doing a lot of tracing.

In a nutshell, my findings were this:

1. "vm-attach-file" (C-c C-a in mail mode):

- Asks for the file name and calls "vm-attach-object" to do the job
with variable "type" for instance set to "application/octet-stream"

- Only when running under XEmacs "vm-attach-object" calls

(vm-mime-set-image-stamp-for-type extent type)

to insert the thumbnail into the extent.

- And, as mentioned above, it works.

2. "vm-mime-display-button-image" (used when reading mail):

- First calls "vm-mime-frob-image-xxxx" which in turn calls several
other functions to insert a PNG into the extent. For some reason
this fails, leaving the "[Unknown/Bad PNG image encoding]" message
in the extent. One other essential thing this function does, how-
ever, is to set the disposition of the layout to "inline". If this
is not done, later middle-clicking the button will fail.

- Later "vm-mime-display-button-image" calls "vm-mime-set-image-
stamp-for-type" (the function also used by "vm-attach-object") to
do its magic, but this function cannot repair the already corrupted
button.

- So apparently somehow function "vm-mime-display-button-image" tries
to insert two thumbnails into the button.

My first attempt therefore was to simply comment out the call to "vm-
mime-frob-image-xxxx" within function "vm-mime-display-button-image".
This displayed a neat button which could however not be middle clicked.
Further tracing then revealed the necessity of the above mentioned
"inline" disposition.

So finally I came up with the following patch which worked at least for
me:

--- vm-mime.el.orig 2011-12-28 00:19:28.000000000 +0200
+++ vm-mime.el 2013-07-30 13:20:05.554100000 +0200
@@ -4559,6 +4559,14 @@
tempfile)
(vm-register-folder-garbage-files (list tempfile))
;; display a thumbnail over the fake extent
+ ;; (do that at most for GNU Emacs (if it should work there),
+ ;; otherwise skip function `vm-mime-frob-image-xxxx' entirely
+ ;; here, because for XEmacs the thumbnail will later again be
+ ;; inserted by function `vm-mime-set-image-stamp-for-type'.
+ ;; However, `vm-mime-frob-image-xxxx' marks the layout as being
+ ;; "inline", which is essential and which therefore is the only
+ ;; thing we do here for XEmacs -- R Woitok 2013-07-30)
+ (if vm-xemacs-p (vm-set-mm-layout-disposition layout '("inline"))
(let ((vm-mime-internal-content-types '("image"))
(vm-mime-internal-content-type-exceptions nil)
(vm-mime-auto-displayed-content-types '("image"))
@@ -4566,7 +4574,7 @@
(vm-mime-use-image-strips nil))
(vm-mime-frob-image-xxxx thumb-extent
"-thumbnail"
- vm-mime-thumbnail-max-geometry))
+ vm-mime-thumbnail-max-geometry)))
;; extract image data, don't need the image itself!
;; if the display was not successful, glyph will be nil
(setq glyph (if vm-xemacs-p

Please run your test suite against this patch, ponder over it using your
insider knowledge, and then tell me what you think. I have detailed
trace output available, if you are interested, but I hesitate to post
this to the list.

Sincerely
Rainer

----------------------------------------------------------------------
| Rainer M Woitok | Phone : [phone] |
| Kolpingstraße 3 | Mobile: [phone] |
| D-63846 Laufach | Mail : ***@Gmail.Com |
| Germany | |
----------------------------------------------------------------------

[Uday Reddy]

Post by Dr Rainer Woitok
Writing a mail and attaching a PDF document to it looks nice, the grey
button line denoting the attachment starts with a cute paper clip to the
left followed by a textual description of the attachment in square
brackets.
After sending off the mail it is stored in my inbox, and there the grey
button line denoting the attachment looks sort of ugly: the cute paper
clip is missing altogether, and the textual description says
"[Unknown/Bad PNG image encoding]PDF: <file name>, [display]".

I am sorry. This problem report is confusing.

Are you saying that reading a message with a PDF attachment gives the
problem? Or, does this have something to do with sending mail?

In any case, I don't see any problems with attachment buttons using:

21.5 (beta31) "ginger" XEmacs Lucid (i586-pc-win32)

It is likely that you are using an out-of-date version of XEmacs. Please
upgrade it.

You might also try setting `vm-imagemagick-convert-program' to nil or
`vm-mime-thumbnail-max-geometry' to nil to disable the images in attachment
buttons.

Post by Dr Rainer Woitok
Back when I was still using "vm-8.1.1" I did a lot of googling and found
several other people having the same complaints. I even found a comment
by you, dated 2011-02-04 and sugesting this having to do with coding
systems. You even offered the following patch then (even though not in

This fix has been incorporated in the standard VM now. So, no need to apply
this patch.

Post by Dr Rainer Woitok
- First calls "vm-mime-frob-image-xxxx" which in turn calls several
other functions to insert a PNG into the extent. For some reason
this fails, leaving the "[Unknown/Bad PNG image encoding]" message
in the extent. One other essential thing this function does, how-
ever, is to set the disposition of the layout to "inline". If this
is not done, later middle-clicking the button will fail.

I am not sure what is meant by "this fails" and which function fails.
Please attach a backtrace at the point of the error if you can.

It is likely that some external program or the image file is bad. All I can
do is to make VM resilient so that it continues normally regardless. For me
to do so, you need to state the problem behaviour as precisely as possible!

Cheers,
Uday

[Dr Rainer Woitok]

Uday,

Post by Uday Reddy
...
I am sorry. This problem report is confusing.

To clarify: Composing and sending mail with attachments works. In the
course of executing function "vm-attach-file" function "vm-mime-set-
image-stamp-for-type" is called when running under XEmacs, and this
function does a clean job.

However, when reading mail containing an attachment in a folder (or in
the INBOX) function "vm-mime-display-button-image" is called, which (as
mentioned in my earlier mail) tries to insert the thumbnail into the
attachment button twice: first using function "vm-mime-frob-image-xxxx"
(which fails to insert the thumbnail into the button but rather inserts
an error message there) and later using function "vm-mime-set-image-
stamp-for-type" which cannot remedy the situation.

Post by Uday Reddy
Are you saying that reading a message with a PDF attachment gives the
problem?

Exactly.

Post by Uday Reddy
...
21.5 (beta31) "ginger" XEmacs Lucid (i586-pc-win32)

This may well be, but "vm-8.2.0b" dates back to December 2011 where a
beta version of XEmacs 21.5 was not yet existing, so I think I could ex-
pect it to work with XEmacs 21.4.

Post by Uday Reddy
It is likely that you are using an out-of-date version of XEmacs. Please
upgrade it.

I am hesitating to upgrade to a beta version of XEmacs. Besides, I have
found a patch which works at least in my environment.

Post by Uday Reddy
You might also try setting `vm-imagemagick-convert-program' to nil or
`vm-mime-thumbnail-max-geometry' to nil to disable the images in attachment
buttons.

This too may well be, but I do not want to disable thumbnails in attach-
ment buttons.

Post by Uday Reddy
...

Post by Dr Rainer Woitok
- First calls "vm-mime-frob-image-xxxx" which in turn calls several
other functions to insert a PNG into the extent. For some reason
this fails, leaving the "[Unknown/Bad PNG image encoding]" message
in the extent. One other essential thing this function does, how-
ever, is to set the disposition of the layout to "inline". If this
is not done, later middle-clicking the button will fail.

I am not sure what is meant by "this fails" and which function fails.
Please attach a backtrace at the point of the error if you can.

The phrase "this fails" means that function "vm-mime-frob-image-xxxx" or
some function called by it does not insert a thumbnail into the attach-
ment button but rather the text "[Unknown/Bad PNG image encoding]". It
does not even seem to recognize the situation as an error, so catching
and backtracing that could be difficult. I have, however, appended a
trace output.

Post by Uday Reddy
It is likely that some external program or the image file is bad.

Again, this may be, but for me the question is, why is function "vm-
mime-display-button-image" at all calling two different functions to in-
sert the thumbnail? At least in my environment calling only the second
function seems sufficient.

Sincerely
Rainer

----------------------------------------------------------------------
| Rainer M Woitok | Phone : [phone] |
| Kolpingstraße 3 | Mobile: [phone] |
| D-63846 Laufach | Mail : ***@Gmail.Com |
| Germany | |
----------------------------------------------------------------------

[Uday Reddy]

Post by Dr Rainer Woitok

Post by Uday Reddy
21.5 (beta31) "ginger" XEmacs Lucid (i586-pc-win32)

This may well be, but "vm-8.2.0b" dates back to December 2011 where a
beta version of XEmacs 21.5 was not yet existing, so I think I could ex-
pect it to work with XEmacs 21.4.

Not necessarily. XEmacs 21.4 is really ancient if I recall correctly. If
you use the latest beta release, you will get the benefit of all the bug
fixes that have been made since then. Beta versions are generally safe to
use, even if they don't have the full functionality that the developers
intended for them.

Post by Dr Rainer Woitok
Again, this may be, but for me the question is, why is function "vm-
mime-display-button-image" at all calling two different functions to in-
sert the thumbnail? At least in my environment calling only the second
function seems sufficient.

If vm-mime-thumbnail-max-geometry is non-nil, VM assumes that you want
thumbnails. If the thumbnail generation "fails" (i.e., gives an error),
then it puts a default paper clip instead. In your environment, the
thumbnail generation is failing (from your point of view), but it is not
giving an error either. So, you are getting a garbage piece of text
instead. The solution is to disable thumbnail generation.

This is not worthy of patching VM because there is nothing wrong with the VM
code. The problem is with your environment.

As far as I am concerned, thumbnail generation is not worthy of either my
time or yours.

Cheers,
Uday

[Dr Rainer Woitok]

Uday,

Post by Uday Reddy
...
Beta versions are generally safe to
use, even if they don't have the full functionality that the developers
intended for them.

Talking about beta versions: "vm-8.2.0b", too, is quite old (almost two
years now), and it would perhaps be a good idea to be more current with
both products, XEmacs and "vm". XEmacs is available as a Mercurial re-
pository, which is fine with me, because I have Mercurial installed on
my computer and am using it a lot myself. I do neither use Bazaar nor
have it installed, but Mercurial can convert a remote Bazaar repos-
itory, provided it can access it. However, the URL

https://code.launchpad.net/~vm/vm/trunk

does not return anything, even if I prefix the "code.launchpad.net" part
with my launchpad account and password. Is there a publicly available
URL I coud use?

Post by Uday Reddy
...
If vm-mime-thumbnail-max-geometry is non-nil, VM assumes that you want
thumbnails.
...
The solution is to disable thumbnail generation.

I wouldn't call it a "solution" but a "workaround". A "solution" would
recognize by itself that for whatever reason thumbnail generation failed
and would then insert the paper clip instead.

But looking at the code and at what "vm-mime-thumbnail-max-geometry"
does I agree with you that setting this configuration variable to nil is
a way cleaner workaround than the patch proposed by me. So I'll go with
your suggestion here.

Post by Uday Reddy
This is not worthy of patching VM because there is nothing wrong with the VM
code. The problem is with your environment.

Yes and no. The cause may well be with my environment, but the way "vm"
handles this should clearly be improved. Particularly because this
clearly wasn't just my environment, else Google wouldn't have turned up
other people suffering the same problem.

Anyway, thanks for your time :-)

Sincerely
Rainer

----------------------------------------------------------------------
| Rainer M Woitok | Phone : [phone] |
| Kolpingstraße 3 | Mobile: [phone] |
| D-63846 Laufach | Mail : ***@Gmail.Com |
| Germany | |
----------------------------------------------------------------------

[Uday Reddy]

Post by Dr Rainer Woitok
itory, provided it can access it. However, the URL
https://code.launchpad.net/~vm/vm/trunk
does not return anything, even if I prefix the "code.launchpad.net" part
with my launchpad account and password. Is there a publicly available
URL I coud use?

The URL for the Bazaar repository, given in the README file, is:

http://bazaar.launchpad.net/~vm/vm/trunk

I don't know how you might need to amend it to access it from Mercurial.

Post by Dr Rainer Woitok

Post by Uday Reddy
This is not worthy of patching VM because there is nothing wrong with
the VM code. The problem is with your environment.

Yes and no. The cause may well be with my environment, but the way "vm"
handles this should clearly be improved. Particularly because this
clearly wasn't just my environment, else Google wouldn't have turned up
other people suffering the same problem.

Please note that VM is a "plugin" for Emacs. If the Emacs environment
doesn't behave right, there is nothing VM can do about it!

The problems that show up on Google are old and defunct. Those problems
have been fixed in VM a long time ago.

Cheers,
Uday