Re: Editing drafts in the queue in ISO-8859-2

[Shenghuo ZHU <zsh@cs.rochester.edu>]

>>>>> Pavel Janik ml <Pavel.Janik@inet.cz> writes:

 >    From: Lars Magne Ingebrigtsen <larsi@gnus.org>
 >    Date: 20 Apr 2000 02:16:19 +0200

 > Hi,

>> Hm.  I wouldn't have been surprised if the charset was wrong, but
>> \x948 would lead me to believe that `prin' or its friends have been
>> involved at some point, which `D e' shouldn't be doing.
>> 
>> Or perhaps you didn't mean a "x" after the backslash?

 > no. I dig deeply and here are the results.

 > 1. I composed test message with ěščřžýáíé (ISO-8859-2) letters in the body.
 > 2. C-c C-c and the message is stored in the queue.
 > 3. I went to the queue group and saw the message in the summary. The message
 > itself looks OK in the message buffer. I tried to D e on it. I received
 > \357\251 in the body. The numbers are random (i.e. not exactly the same I've
 > got, but you got the point :-). When I press C-x k RET here, the message goes
 > into drafts folder from the queue.

 > BAD.

It is because the message from nndraft:queue is not decoded.  Now,
this bug is fixed in 5.8.5. 

 > 1. I composed another test message with ěščřžýáíé (ISO-8859-2) letters in the
 >    body and sent it to queue.
 > 2. I tried to press `e' in the summary. Everything is ok and the message _is_
 >    readable with correct charset. I can add another ISO 8859-2 characters in
 >    it and they are showed ok. Then I pressed C-c C-c to end the edits. The
 >    message buffer is then switched into \357\251 chars like above. The I can
 >    show another message and came back to my test message again and it is
 >    showed in the message buffer correctly. And it is sent correctly.

 > Hmm, I accidentally pressed D e in the message buffer in the queue group and
 > got an error message. Hm, D is gnus-article-read-summary-keys in the message
 > buffer but when I'm in the message buffer in the queue group, Emacs is waiting
 > for another key and shows D- in the minibuffer... Maybe this will help you to
 > debug it.

 > Backtrace:

 > Signaling: (wrong-type-argument commandp 1)
 >   call-interactively(1)
 >   gnus-article-read-summary-keys(nil)
 > * call-interactively(gnus-article-read-summary-keys)

[...]

lookup-key returns 1. Weird. This one is not fixed.

-- 
Shenghuo