Inconsistencies regarding nil coding-system

Inconsistencies regarding nil coding-system

[Eli Zaretskii]

  (coding-system-change-eol-conversion nil 'unix) => nil
  (coding-system-change-text-conversion 'latin-1-dos nil) => undecided-dos
  (coding-system-base nil) => no-conversion

When primitives that encode/decode text accept nil as their
coding-system argument, they use `undecided' (AFAIK).  So the second
result above looks reasonable, but the first and the last are
inconsistent, and the last one is downright surprising.

Any reasons not to change coding-system-change-eol-conversion and
coding-system-base to consistently treat nil as `undecided'?  (If
agreed to, I suggest to make this change only on the trunk, not on the
release branch.)

Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <83aakcvbtp.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>   (coding-system-change-eol-conversion nil 'unix) => nil
>   (coding-system-change-text-conversion 'latin-1-dos nil) => undecided-dos
>   (coding-system-base nil) => no-conversion

> When primitives that encode/decode text accept nil as their
> coding-system argument, they use `undecided' (AFAIK).  So the second
> result above looks reasonable, but the first and the last are
> inconsistent, and the last one is downright surprising.

> Any reasons not to change coding-system-change-eol-conversion and
> coding-system-base to consistently treat nil as `undecided'?  (If
> agreed to, I suggest to make this change only on the trunk, not on the
> release branch.)

When I first introduced coding-system, nil was for
no-conversion, and t was for undecided, and as time passed,
we have shifted to `no-conversion' and `undecided'.  But,
some old codes still treat nil for `no-conversion' and new
codes consider nil as "unspecified" and thus treat it as
`undecided'.  Perhaps, ver. 24 is a good timing to wipe out
this confusion, but I'm not sure how to treat nil.  Nil
should usually mean "unspecified", and what exactly
"unspecified" means depends on a situaion.

---
Kenichi Handa
handa@m17n.org

Re: Inconsistencies regarding nil coding-system

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 13 Dec 2010 16:45:53 +0900
> 
> some old codes still treat nil for `no-conversion'

I see a few of such places in coding.c; are there others?

If coding.c is the only place, I think we can safely change it to
tread nil as unidecided.

> and new codes consider nil as "unspecified" and thus treat it as
> `undecided'.  Perhaps, ver. 24 is a good timing to wipe out this
> confusion, but I'm not sure how to treat nil.  Nil should usually
> mean "unspecified", and what exactly "unspecified" means depends on
> a situaion.

What would be a situation where it's inappropriate to interpret nil as
undecided?

Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <834oahiute.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > some old codes still treat nil for `no-conversion'

> I see a few of such places in coding.c; are there others?

I don't remember at the momemnt, but mule.el, mule-cmds.el,
and mule-util.el should be checked.

> If coding.c is the only place, I think we can safely change it to
> tread nil as unidecided.

> > and new codes consider nil as "unspecified" and thus treat it as
> > `undecided'.  Perhaps, ver. 24 is a good timing to wipe out this
> > confusion, but I'm not sure how to treat nil.  Nil should usually
> > mean "unspecified", and what exactly "unspecified" means depends on
> > a situaion.

> What would be a situation where it's inappropriate to interpret nil as
> undecided?

For instance, coding-system-for-read being bound to nil and
to `undecided' have different meanings.

---
Kenichi Handa
handa@m17n.org

Re: Inconsistencies regarding nil coding-system

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 14 Dec 2010 10:41:18 +0900
> 
> > What would be a situation where it's inappropriate to interpret nil as
> > undecided?
> 
> For instance, coding-system-for-read being bound to nil and
> to `undecided' have different meanings.

You mean that `undecided' bypasses the various preferences?  If not,
then what's the difference between `undecided' and nil in this case?

Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <83r5dlgg0d.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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.

---
Kenichi Handa
handa@m17n.org

Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <tl7aak90xy1.fsf@m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> In article <83r5dlgg0d.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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.

---
Kenichi Handa
handa@m17n.org

Re: Inconsistencies regarding nil coding-system

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Tue, 14 Dec 2010 16:44:47 +0900
> 
> In article <tl7aak90xy1.fsf@m17n.org>, Kenichi Handa <handa@m17n.org> writes:
> 
> > In article <83r5dlgg0d.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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.

Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <E1PSR8V-0000hB-2m@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

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

Sure.

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

Ok, I agree.

---
Kenichi Handa
handa@m17n.org

Inconsistencies regarding nil coding-system

[Eli Zaretskii]

  (coding-system-change-eol-conversion nil 'unix) => nil
  (coding-system-change-text-conversion 'latin-1-dos nil) => undecided-dos
  (coding-system-base nil) => no-conversion

When primitives that encode/decode text accept nil as their
coding-system argument, they use `undecided' (AFAIK).  So the second
result above looks reasonable, but the first and the last are
inconsistent, and the last one is downright surprising.

Any reasons not to change coding-system-change-eol-conversion and
coding-system-base to consistently treat nil as `undecided'?  (If
agreed to, I suggest to make this change only on the trunk, not on the
release branch.)