Re: [VM] Cached data with international characters

[John Stoffel]

>>>>> "Uday" == Uday Reddy <address@hidden> writes:

Uday> VM stores in a special header (called X-VM-v5-data) certain internal data
Uday> which it remembers between VM sessions.  These are things like the author,
Uday> recipients, subject etc., which are primarily used for displaying summary
Uday> lines.

Uday> The trouble is that message headers can only have ASCII characters but the
Uday> data that needs to be remembered can be in other character sets.  Rob F
Uday> introduced a way to encode the cached data headers in VM 8.0.10 (way back 
in
Uday> 2008).  The release notes say:

Uday>     * Correctly store UTF-8 strings in the X-VM-v5-Data header to avoid
Uday>       corruption of summary lines. (Thanks to Yuning Feng for reporting)

Uday>     * Correctly encode multibyte subjects. (Thanks to Yuning Feng for the
Uday>       patch) 

Uday> However, I am unable to find any place where this data is being decoded.
Uday> So, it is surprising that things stayed this way for so long and nobody
Uday> reported any problems!

Uday> Are there problems?  Do people that receive messages with
Uday> international character sets in the headers find that VM is
Uday> mishandling them in the Summary lines?

This might explain some of the wierd issues I've been seeing with
emails, but I generally tend to run VM inside emacs in a gnu screen
session, so I'm very text based.  And what happens is that sometimes
when I read a message, then move to the next message parts of the
screen aren't re-drawn properly, which is usually fixed with an C-l to
force a re-fresh.

This happens with both 8.2.0b (emacs 23.1.1 centos) and 8.1.2 (debian
squeeze emacs 23.2.1), though I suspect I run into this more often
with 8.1.2 just because I'm usually reading my home email that way.  

So I've recently tried moving over to TMUX instead of gnu screen, but
I still see the problem randomly.  If you can come up with a text
case, I'd be happy to test things out and let you now how it looks.

John