|
From: | Glenn Morris |
Subject: | bug#6187: 23.1; can't save: "Wrong type argument: number-of-marker-p, nil" |
Date: | Thu, 17 Jun 2010 03:52:07 -0400 |
User-agent: | Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Ryo Furue wrote: > apply(min nil) > select-safe-coding-system-interactively(1 1362 (utf-8 > adobe-standard-encoding next mac-roman gb18030 utf-7 utf-16 > utf-16be-with-signature utf-16le-with-signature utf-16be utf-16le > x-ctext iso-2022-7bit utf-8-auto utf-8-with-signature emacs-mule > raw-text iso-2022-8bit-ss2 utf-7-imap utf-8-emacs no-conversion > compound-text-with-extensions ctext-no-compositions > iso-2022-7bit-lock iso-2022-7bit-ss2) (japanese-iso-8bit-unix) nil > utf-8) So: select-safe-coding-system-interactively is called with UNSAFE = (japanese-iso-8bit-unix) This is presumably because it does not appear in the list of codings returned by the call to find-coding-systems-region in select-safe-coding-system (passed to select-safe-coding-system-interactively as 3rd argument above). Yet when select-safe-coding-system-interactively calls unencodable-char-position with coding == japanese-iso-8bit-unix, it returns nil, meaning it can encode the region. So apparently it both can and cannot encode the region. One could paper over this by excluding non-numeric elements in (goto-char (apply 'min (mapcar #'(lambda (x) (car (cadr x))) unsafe)))) But I guess the real bug is that find-coding-systems-region and unencodable-char-position somehow manage to disagree. An example of a file that triggers the problem would probably be very helpful.
[Prev in Thread] | Current Thread | [Next in Thread] |