← Back to team overview

vm team mailing list archive

[Bug 430521] Re: Wrong charset for outgoing mail under Emacs 23

 

Giacomo Boffi has reported the following problem with VM 8.1.0 under
XEmacs 21.5:

   From: Giacomo Boffi <giacomo.boffi@xxxxxxxxx>
   Subject: [8.1.0, XEmacs] Invalid argument: No such coding system, us-ascii
   Newsgroups: gnu.emacs.vm.info
   Date: Fri, 19 Mar 2010 10:15:33 +0100
   Message-ID: <86bpekvfii.fsf@xxxxxxxxxxxxxxxxxxxxx>

   I pressed "Q" to save my inbox and quit VM, but my inbox was not
saved

   this is what i see in my lossage buffer

   Invalid argument: No such coding system, us-ascii
   [...]

   and the inbox was not saved! what can i do to save the inbox (and
   maybe revert to 8.0.12)?


** Attachment added: "Debugger backtrace"
   http://launchpadlibrarian.net/41297638/backtrace

-- 
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.