[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistencies regarding nil coding-system

From: Eli Zaretskii
Subject: Re: Inconsistencies regarding nil coding-system
Date: Tue, 14 Dec 2010 04:25:31 -0500

> From: Kenichi Handa <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Tue, 14 Dec 2010 16:44:47 +0900
> In article <address@hidden>, Kenichi Handa <address@hidden> writes:
> > In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> > > > For instance, coding-system-for-read being bound to nil and
> > > > to `undecided' have different meanings.
> > > You mean that `undecided' bypasses the various preferences?
> > Yes.
> What I actually meant is that if coding-system-for-read is
> bound to undecided, insert-file-contents ignores coding:
> tag, etc and always performs coding-system detection based
> on the byte sequence of a file.

Right.  But I don't see this as being relevant to the issue at hand:
coding-system-for-read is explicitly advertised to treat the nil value
specially.  IOW, with coding-system-for-read, nil is _not_ a coding
system, it's a flag with a well documented meaning.

In the context of this discussion, nil is relevant for variables and
arguments that must have a valid coding-system as their value.  (We
treat nil as "valid" coding-system only for practical purposes.)
Variables like coding-system-for-read, coding-system-for-write,
last-next-selection-coding-system, etc. are not in this group.

And in any case, nil does _not_ mean no-conversion for these
variables, either.

So, to summarize, how about if we change the interpretation of nil in
this context to `undecided', on the trunk only?  If there are problems
with that, we will have ample time to fix them, I think.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]