>>>>> "Uday" == Uday Reddy <[email protected]> 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
