Re: Inconsistencies regarding nil coding-system

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> 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
address@hidden