all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Inconsistencies regarding nil coding-system
@ 2010-12-11 10:33 Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2010-12-11 10:33 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Inconsistencies regarding nil coding-system
@ 2010-12-11 10:33 Eli Zaretskii
  2010-12-13  7:45 ` Kenichi Handa
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2010-12-11 10:33 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-11 10:33 Inconsistencies regarding nil coding-system Eli Zaretskii
@ 2010-12-13  7:45 ` Kenichi Handa
  2010-12-13 14:58   ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Kenichi Handa @ 2010-12-13  7:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-13  7:45 ` Kenichi Handa
@ 2010-12-13 14:58   ` Eli Zaretskii
  2010-12-14  1:41     ` Kenichi Handa
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2010-12-13 14:58 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-13 14:58   ` Eli Zaretskii
@ 2010-12-14  1:41     ` Kenichi Handa
  2010-12-14  4:00       ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Kenichi Handa @ 2010-12-14  1:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-14  1:41     ` Kenichi Handa
@ 2010-12-14  4:00       ` Eli Zaretskii
  2010-12-14  4:40         ` Kenichi Handa
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2010-12-14  4:00 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-14  4:00       ` Eli Zaretskii
@ 2010-12-14  4:40         ` Kenichi Handa
  2010-12-14  7:44           ` Kenichi Handa
  0 siblings, 1 reply; 10+ messages in thread
From: Kenichi Handa @ 2010-12-14  4:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-14  4:40         ` Kenichi Handa
@ 2010-12-14  7:44           ` Kenichi Handa
  2010-12-14  9:25             ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Kenichi Handa @ 2010-12-14  7:44 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: eliz, emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-14  7:44           ` Kenichi Handa
@ 2010-12-14  9:25             ` Eli Zaretskii
  2010-12-14 11:03               ` Kenichi Handa
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2010-12-14  9:25 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Inconsistencies regarding nil coding-system
  2010-12-14  9:25             ` Eli Zaretskii
@ 2010-12-14 11:03               ` Kenichi Handa
  0 siblings, 0 replies; 10+ messages in thread
From: Kenichi Handa @ 2010-12-14 11:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2010-12-14 11:03 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-11 10:33 Inconsistencies regarding nil coding-system Eli Zaretskii
2010-12-13  7:45 ` Kenichi Handa
2010-12-13 14:58   ` Eli Zaretskii
2010-12-14  1:41     ` Kenichi Handa
2010-12-14  4:00       ` Eli Zaretskii
2010-12-14  4:40         ` Kenichi Handa
2010-12-14  7:44           ` Kenichi Handa
2010-12-14  9:25             ` Eli Zaretskii
2010-12-14 11:03               ` Kenichi Handa
  -- strict thread matches above, loose matches on Subject: below --
2010-12-11 10:33 Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.