vm team mailing list archive

[Ulrich Müller <ulm@xxxxxxxxxx>]

** Changed in: vm
       Status: Fix Released => In Progress

** Changed in: vm
    Milestone: 8.1.0b => 8.1.1

-- 
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: In Progress

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.