vm-error: wrong-type-argument stringp =\?iso-8859-1\?Q\?
Ingo Wardinski
I'm using vm8.0.12 with XEmacs 21.4 (patch 22) and I get sometimes
this error message:
wrong-type-argument stringp =\?iso-8859-1\?Q\?
Did anyone see that before and could give me a hint how to avoid this?
tia
ingo
The backtrace looks like:
Debugger entered--Lisp error: (wrong-type-argument stringp =\?iso-8859-1\?Q\?)
string-match("=\\?\\([^?*]+\\)\\(\\*\\([^?*]+\\)\\)?\\?\\([BbQq]\\)\\?\\([^?]+\\)\\?=" =\?iso-8859-1\?Q\?)
vm-decode-mime-encoded-words-in-string(=\?iso-8859-1\?Q\?)
(vm-reencode-mime-encoded-words-in-string (vm-decode-mime-encoded-words-in-string (vm-su-subject vm-su-message)))
(format "\"%s\"" (vm-reencode-mime-encoded-words-in-string (vm-decode-mime-encoded-words-in-string ...)))
(list (quote number) " " (quote mark) (format "%s %s %s.%s %s %s " (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...)) (quote group-begin) -38 38 (quote thread-indent) (format "\"%s\"" (vm-reencode-mime-encoded-words-in-string ...)) (quote group-end) " \n")
eval((list (quote number) " " (quote mark) (format "%s %s %s.%s %s %s " (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...) (vm-reencode-mime-encoded-words-in-string ...)) (quote group-begin) -38 38 (quote thread-indent) (format "\"%s\"" (vm-reencode-mime-encoded-words-in-string ...)) (quote group-end) " \n"))
vm-summary-sprintf("%2n %*%a %-20.20F %02d.%02M %H %8c %-38.38(%I\"%s\"%) \n" [[#<marker at 11527004 in INBOX 0x4a786c8> #<marker at 11527037 in INBOX 0x4a786f8> nil #<marker at 11528525 in INBOX 0x4ace978> #<marker at 11535941 in INBOX 0x4a78728> #<marker at 11535942 in INBOX 0x4a78758>] ["162" "162" nil nil nil <<>> <-- From_ "161" #<buffer "INBOX"> nil nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil] ["7416" "Thursday" "11" "June" "2009" "10:46:35" "+0200" "Franz Ossing" "oss...@gfz-potsdam.de" nil nil =\?iso-8859-1\?Q\? "D=FCrre?= und =?iso-8859-1?Q?=DCberschwemmungen?= in Jahresr ingen tropischer =?iso-8859-1?Q?B=E4ume" ?= "^To:" "6" nil "6" nil nil (number " " mark " Franz Ossing 11.06 10:46 7416 " group-begin -38 38 thread-indent =\?iso-8859-1\?Q\? "\"D=FCrre?= und =?iso-8859-1?Q?=DCberschwemmungen?= in Jahresr ingen tropischer =?iso-8859-1?Q?B=E4ume\"" ?= group-end " \n") nil nil nil nil nil nil nil] [nil <v> nil nil nil nil]] t)
vm-su-summary([[#<marker at 11527004 in INBOX 0x4a786c8> #<marker at 11527037 in INBOX 0x4a786f8> nil #<marker at 11528525 in INBOX 0x4ace978> #<marker at 11535941 in INBOX 0x4a78728> #<marker at 11535942 in INBOX 0x4a78758>] ["162" "162" nil nil nil <<>> <-- From_ "161" #<buffer "INBOX"> nil nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil] ["7416" "Thursday" "11" "June" "2009" "10:46:35" "+0200" "Franz Ossing" "oss...@gfz-potsdam.de" nil nil =\?iso-8859-1\?Q\? "D=FCrre?= und =?iso-8859-1?Q?=DCberschwemmungen?= in Jahresr ingen tropischer =?iso-8859-1?Q?B=E4ume" ?= "^To:" "6" nil "6" nil nil (number " " mark " Franz Ossing 11.06 10:46 7416 " group-begin -38 38 thread-indent =\?iso-8859-1\?Q\? "\"D=FCrre?= und =?iso-8859-1?Q?=DCberschwemmungen?= in Jahresr ingen tropischer =?iso-8859-1?Q?B=E4ume\"" ?= group-end " \n") nil nil nil nil nil nil nil] [nil <v> nil nil nil nil]])
vm-do-summary(nil)
vm-do-needed-summary-rebuild()
#<compiled-function (b) "...(43)" [vm-summary-buffer vm-use-toolbar vm-buffers-needing-undo-boundaries b get-buffer symbol-name intern buffer-name vm-check-for-killed-summary vm-toolbar-support-possible-p vm-toolbar-update-toolbar vm-do-needed-renumbering vm-do-needed-summary-rebuild vm-do-needed-mode-line-update] 4>(INBOX)
mapatoms(#<compiled-function (b) "...(43)" [vm-summary-buffer vm-use-toolbar vm-buffers-needing-undo-boundaries b get-buffer symbol-name intern buffer-name vm-check-for-killed-summary vm-toolbar-support-possible-p vm-toolbar-update-toolbar vm-do-needed-renumbering vm-do-needed-summary-rebuild vm-do-needed-mode-line-update] 4> [INBOX 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0])
vm-update-summary-and-mode-line()
vm-summarize(t nil)
byte-code("..." [f full-startup access-method remote-spec buffer-file-coding-system folder string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
#<compiled-function (&optional folder read-only access-method) "...(18)" [access-method read-only folder vm-session-initialization boundp vm-session-beginning vm done (byte-code "\n¬¯.®‚.K. Q«‘ ;« Æ.Q \"«†Ç. .ª“.R« ;«‹Æ.R \"«„È. .)É.!?ʉ‰‰‰‰‰.A. D.B.C.S.G.\nÈa«áË.!‰.¬…ÌÍ.\"ˆ. DÎ !Î Ï\"Πω#.H.I‰.J.H˜¬žÐ.H!¬˜Ð.J!«‡ÊÑÒ ˆª‹Ð.I!«…ÊÓÔ ˆÐ.J!«….J.ªŽÐ.I!«….I.ªƒ.H.+ª•\nÇa« . ÕÖ !8® . D× !.É.!«ƒ.ªõ.®†Ø.K.L\".@Ù.@!«‡ÌÚ.@\"ªÜÛ.@!®Ö.L«†Ø.L!®‚.TÏʉ‰.U«ƒÜªˆ.V«ƒÜª Ý.].^._.`.a.TÞß.@\"ˆà.@! ®….®‚.K‰.W.M@k¬‡.W.MB.M)Þá.@\"ˆ..)‰.Sqˆ\nâs« .Dã k¬†ä.DÏ\"ˆ.N«ˆ.b«„åÊ!ˆ.U¬„.V«¿æ !æç!a¬¶æ !æè!a¬æ !æé!a¬¤æ !æê!a¬›Êë .X.OìŽíed #ˆîÜÊ\"ˆïed #ˆ+.N«ˆ ¬…îÝÊ\"ˆ.N«¿ð !ðñ!a¬¶ð !ðò!a¬ð !ðó!a¬¤ð !ðÜ!a¬›Êë .X.OôŽíed #ˆîÝÊ\"ˆïed #ˆ+õ ˆö ˆë ¬ƒ÷.c.døa?.C.E‹ë ?†ùú .E\"‰.A® .e®‹ûü!®†.C‚.O.<.C«¹ýp!ˆþ÷!ˆÿ÷!ˆ o. ˆ p.\n!ˆ\nÈa«ˆ q. !ˆª‹\nÇa«† r. !ˆë ¬† s. .G t.Ê.G?ÊÏ$ˆ.C«¢.G¬ž u. ˆ v. ˆ w. ˆ x. ˆ y. ˆ z. ˆ.C«… {. ˆ «—.F«“ |. }.
«… ~.ªƒ .\"ˆ ««.P®….Y® p.Z €. Z‰.FC.F®ƒ . ‚.D$ˆ.[«… ƒ. ˆ) «” „. .B.E«Š …. E.fA\"ˆ †. ˆ ‡. ˆ ˆ. ˆ.g«‹ ‰. «… Š. ˆ «Ñ ‹. «‹.A¬‡ Œ.ÏÊ\"ˆ.P«‘.h« .i«‰.[«… ƒ. ˆ.j«— €.ʉ.FC.F®ƒ . ‚.D$ˆª Š . P®….Y® p!ˆ).k« .\\ƒ.A?.\\ Ž. ˆ) . .!ˆ «Ž.A«ŠÞ ‘. ’.!!ˆ «„.A«‰ “. ”.Ï\"ˆ «…Þ.B!ˆ.l«¸.m¬´.<¬°Þ •. E®‚ã \"ˆ –.Ï!«˜ „. .B †. «‡ Ž. ˆª… ‡. ˆÞ.B!ˆt•.n? —. ˆ ˜. ?„Þ.B!. ‡" ... 9)] 4 ("/usr/local/lib/xemacs/xemacs-packages/lisp/vm/vm.elc" . 909) (list nil current-prefix-arg)>(nil nil)
call-interactively(vm)
Ralf Fassel
| I'm using vm8.0.12 with XEmacs 21.4 (patch 22) and I get sometimes
| this error message:
| wrong-type-argument stringp =\?iso-8859-1\?Q\?
|
| Did anyone see that before and could give me a hint how to avoid this?
Might be related to
Message-ID: <umyi...@a1i15.kph.uni-mainz.de>
Message-ID: <yga1vuy...@akutech.de>
in gnu.emacs.vm.bug.
I had the same problem and reverted back to vm 8.0.10.
R'
anakreon
vm-decode-mime-encoded-words-in-string: Wrong type argument: stringp, =
\?iso-2022-jp\?Q\?
Version of vm is: 8.0.12
GNU emacs
Now I can do nothing with my inbox. emacs can not save the file
because before saving this error message appears and saving is
aborted.
Philippe Queinnec
=?iso-8859-1?Q?#("...." ...) is inserted in the X-VM-v5-Data field
(precisely in the 15th field of the second vector), but I don't know why.
To correct a corrupted file, edit it with find-file and remove the
X-VM-v5-Data field containing such a string (when in doubt, remove all
X-VM-v5-Data fields). Be careful to remove the two continuation lines.
However the problem will reappear soon...
Phil
nor...@yahoo.com
iso-latin-1 (iso-8859-1) and apparently iso-2022-jp as well.
Suppose you receive an email whose subject reads:
Subject: ééé vm-error
Then it gets encoded as
Subject: =?iso-8859-1?Q?=E9=E9=E9_vm-error?=
As Philippe Queinnec puts it what happens is that plain text
=?iso-8859-1?Q?#("=E9=E9=E9_vm-error?=" ...)
gets inserted in the X-VM-v5-Data field.
If you edit the folder as a regular file and remove the leading =?iso-8859-1?Q?
in the X-VM-v5-Data field AND in the subject line then the problems disappears.
What is strange is that there no such problem when using utf-8 encoding... I
don't know why.
--
Ulrich Mueller
> This problem appears every time you get an email whose subject is
> encoded using iso-latin-1 (iso-8859-1) and apparently iso-2022-jp
> as well.
>
> Suppose you receive an email whose subject reads:
>
> Subject: ��� vm-error
>
> Then it gets encoded as
>
> Subject: =?iso-8859-1?Q?=E9=E9=E9_vm-error?=
>
> As Philippe Queinnec puts it what happens is that plain text
>
> =?iso-8859-1?Q?#("=E9=E9=E9_vm-error?=" ...)
>
> gets inserted in the X-VM-v5-Data field.
Does the patch included below fix the problem? It reverts the following
change that was introduced with vm-8.0.10:
<http://bazaar.launchpad.net/~hack-robf/viewmail/trunk/revision/453.6.28>
I haven't noticed any negative side effects (with GNU Emacs 23.1).
Ulrich
--- vm-8.0.12-orig/lisp/vm-folder.el 2008-11-05 21:04:35.000000000 +0100
+++ vm-8.0.12/lisp/vm-folder.el 2009-09-11 23:22:15.000000000 +0200
@@ -1806,9 +1806,8 @@
(let ((print-escape-newlines t))
(prin1-to-string attributes))
"\n\t"
- (vm-mime-encode-words-in-string
- (let ((print-escape-newlines t))
- (prin1-to-string cache)))
+ (let ((print-escape-newlines t))
+ (prin1-to-string cache))
"\n\t"
(let ((print-escape-newlines t))
(prin1-to-string (vm-labels-of m)))
nor...@yahoo.com
UM> Does the patch included below fix the problem?
Seems to be working alright.
UM> I haven't noticed any negative side effects (with GNU Emacs 23.1).
Neither have I.
Thank you.
--
Uday S Reddy
>
> Does the patch included below fix the problem? It reverts the following
> change that was introduced with vm-8.0.10:
> <http://bazaar.launchpad.net/~hack-robf/viewmail/trunk/revision/453.6.28>
Hi Ulrich, then what should be done about this problem, reported by
Yuning Feng:
Cheers,
Uday
Ulrich Mueller
>> Does the patch included below fix the problem? It reverts the following
>> change that was introduced with vm-8.0.10:
>> <http://bazaar.launchpad.net/~hack-robf/viewmail/trunk/revision/453.6.28>
> then what should be done about this problem, reported by Yuning Feng:
> http://groups.google.com/group/gnu.emacs.vm.bug/browse_thread/thread/cb57d4b8a884432/1b0896c5ee4a4e60?q=should+not+write+the+code+point#
Hi Uday,
can you reproduce his original problem? I had checked at the time, and
I failed to do so (with Emacs 23.1 and VM 8.0.9). Unfortunately, Feng
didn't say what Emacs version he was using.
Since the X-VM-v5-Data information is supposed to be read by the Lisp
reader, just writing it with "prin1" or "prin1-to-string" should DTRT.
Surrounding this by vm-mime-encode-words-in-string can only break
things.
What could be tried is to let-bind print-escape-multibyte to t, as in
the patch below (which is completely untested). This should encode
characters in a way that is compatible with the Lisp reader:
(prin1 "���")
--> "���"
(let ((print-escape-multibyte t))
(prin1 "���"))
--> "\x00e4\x00f6\x00fc"
Ulrich
--- lisp/vm-folder.el~
+++ lisp/vm-folder.el
@@ -1807,7 +1807,8 @@
(prin1-to-string attributes))
"\n\t"
(vm-mime-encode-words-in-string
- (let ((print-escape-newlines t))
+ (let ((print-escape-newlines t)
+ (print-escape-multibyte t))
(prin1-to-string cache)))
Uday S Reddy
> can you reproduce his original problem? I had checked at the time, and
> I failed to do so (with Emacs 23.1 and VM 8.0.9). Unfortunately, Feng
> didn't say what Emacs version he was using.
Actually, I don't get either his problem or your problem in the 8.1 devo
version, which I have been using since early 2008 with Emacs 22. I
might have had your problem with Emacs 21, but it was a long time ago
and I can't remember it well.
I have just dug through my mail folders and found several encoded header
strings of iso-8859-1. So, I am inclined to believe that version 8.1
will probably work fine for you and I encourage you to try it. If it
doesn't, we will come back and try these ideas.
Cheers,
Uday
Ulrich Mueller
> What could be tried is to let-bind print-escape-multibyte to t, as in
> the patch below (which is completely untested).
And wrong... The call to "vm-mime-encode-words-in-string" should be
removed of course, as in the patch included below.
Ulrich
--- lisp/vm-folder.el~
+++ lisp/vm-folder.el
@@ -1806,9 +1806,9 @@
(let ((print-escape-newlines t))
(prin1-to-string attributes))
"\n\t"
- (vm-mime-encode-words-in-string
- (let ((print-escape-newlines t))
- (prin1-to-string cache)))
+ (let ((print-escape-newlines t)
+ (print-escape-multibyte t))
+ (prin1-to-string cache))
"\n\t"
(let ((print-escape-newlines t))
(prin1-to-string (vm-labels-of m)))
Uday S Reddy
> Since the X-VM-v5-Data information is supposed to be read by the Lisp
> reader, just writing it with "prin1" or "prin1-to-string" should DTRT.
> Surrounding this by vm-mime-encode-words-in-string can only break
> things.
An argument for not going down this route is the fact that the VM mail
folders are supposed to be mboxes, whose format is described in RFC
2822. According to the standard, a message is supposed to be a sequence
of ASCII characters, with codes in the range 1..127. In principle, it
should be possible to read a VM folder using some other mbox-handling
mail client, which might assume that the folders satisfy the standard.
So it seems to me that encoding non-ASCII characters in the headers is
the right thing to do. If these headers are not getting decoded
correctly when the folders are loaded, then we should deal with that
problem. Putting non-ASCII strings in headers seems to me to be a
cop-out that can lead to trouble down the road.
I don't know. I am just being a bit conservative I suppose. If people
can try out the current version 8.1 and find that the problem still
exists, I am happy to revisit it.
Cheers,
Uday
Julian Bradfield
> Ulrich Mueller wrote:
>
>> Since the X-VM-v5-Data information is supposed to be read by the Lisp
>> reader, just writing it with "prin1" or "prin1-to-string" should DTRT.
>> Surrounding this by vm-mime-encode-words-in-string can only break
>> things.
>
> An argument for not going down this route is the fact that the VM mail
> folders are supposed to be mboxes, whose format is described in RFC
> 2822. According to the standard, a message is supposed to be a sequence
> of ASCII characters, with codes in the range 1..127. In principle, it
> should be possible to read a VM folder using some other mbox-handling
> mail client, which might assume that the folders satisfy the standard.
Moreover, if you put binary data in headers, how do you know what
coding-system it's in?