GNU bug report logs -
#6187
23.1; can't save: "Wrong type argument: number-of-marker-p, nil"
Previous Next
Reported by: Ryo Furue <furue <at> hawaii.edu>
Date: Fri, 14 May 2010 06:22:02 UTC
Severity: normal
Merged with 5948
Found in version 23.1
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 12 years and 235 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.