GNU bug report logs - #1187
23.0.60; Cannot read vline.el - invalid read syntax

Previous Next

Full log

Message #190 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: drew.adams <at> oracle.com, 1187 <at> debbugs.gnu.org,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1187: 23.0.60; Cannot read vline.el - invalid read syntax
Date: Tue, 21 Oct 2008 11:40:42 +0900

In article <uy70jilch.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> It's vline.el, and you can download it from here:

>   http://www.emacswiki.org/cgi-bin/wiki/vline.el

> (It is better to download, to avoid any possible transformations of
> the file in mail transfer.)

Ok, I found what is the problem.  In Emacs 22, iso-8859-1 is
a coding of type `iso-2022', but in Emacs 23, it's of type
`charset', and I forgot to handle latin-extra-code-table
(which has nil for the byte 0x80) in the detector of that
kind of coding system.  As I've just installed a fix, the
latest code should detect vline.el correctly as utf-8.

But, the reason why it's detected as utf-8 is because the
file contains a byte 0x80.  If a file doesn't contain a byte
in the range 0x80..0x9F and nil in latin-extra-code-table,
it's impossible to distinguish iso-latin-1 from utf-8.

So, in general, it's a good idea to add coding-tag: utf-8
for utf-8 files.

---
Kenichi Handa
handa <at> ni.aist.go.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.