vm team mailing list archive
-
vm team
-
Mailing list archive
-
Message #00714
[Bug 430521] Re: Wrong charset for outgoing mail under Emacs 23
** Branch linked: lp:vm/8.1.x
--
Wrong charset for outgoing mail under Emacs 23
https://bugs.launchpad.net/bugs/430521
You received this bug notification because you are a member of VM
development team, which is the registrant for VM (defunct).
Status in VM - Goto http://launchpad.net/vm for active development: Fix Released
Status in VM (View Mail) for Emacs: Fix Committed
Bug description:
[Already reported at gnu.emacs.vm.bug]
For an outgoing message containing only latin-1 characters, e.g.
German umlauts, VM 8.0.12 under GNU Emacs 23 (both in their default
configuration) will use "iso-2022-jp" as encoding. That is not a
reasonable default.
The same VM version under GNU Emacs 22 will correctly encode the
message with "iso-8859-1".
Investigating the problem, I've found two problems in function
vm-determine-proper-charset:
1. The keys of vm-mime-mule-coding-to-charset-alist are symbols, not
strings. So the following assq (occuring in similar form in the
code four times) will always fail, because vm-coding-system-name
returns a string:
(assq (vm-coding-system-name sys)
vm-mime-mule-coding-to-charset-alist)
The call to vm-coding-system-name should just be omitted and its
argument used directly instead.
2. Function vm-charsets-in-region is aliased to find-charset-region.
In Emacs 23, there really aren't separate character sets any
more, and find-charset-region will return the first match from
charset-priority-list. In Emacs's default configuration, this can
only be a subset of (iso-8859-1 ascii unicode).
I believe that in Emacs 23 it's much easier to determine the proper
coding system by calling check-coding-systems-region. The detour
via character sets seems no longer necessary.
I attach a patch for vm-mime.el that should fix both problems.
It is against 8.0.12, but should also apply to the current BZR trunk.
(I didn't fix indentation of the code in all cases, in order to keep the
patch small and human-readable.)
Unfortunately, the patch adds yet another case distinction. However,
I don't see how this could be avoided.