From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Inconsistencies regarding nil coding-system Date: Tue, 14 Dec 2010 04:25:31 -0500 Message-ID: References: <83aakcvbtp.fsf@gnu.org> <834oahiute.fsf@gnu.org> <83r5dlgg0d.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1292318785 25935 80.91.229.12 (14 Dec 2010 09:26:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Dec 2010 09:26:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 14 10:26:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PSR9J-0005tE-1o for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2010 10:26:21 +0100 Original-Received: from localhost ([127.0.0.1]:37503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSR9E-0002o8-VK for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2010 04:26:17 -0500 Original-Received: from [140.186.70.92] (port=46236 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSR8a-0002YN-1y for emacs-devel@gnu.org; Tue, 14 Dec 2010 04:25:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSR8Y-0003Gt-50 for emacs-devel@gnu.org; Tue, 14 Dec 2010 04:25:35 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:55662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSR8Y-0003Go-1s for emacs-devel@gnu.org; Tue, 14 Dec 2010 04:25:34 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PSR8V-0000hB-2m; Tue, 14 Dec 2010 04:25:31 -0500 In-reply-to: (message from Kenichi Handa on Tue, 14 Dec 2010 16:44:47 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133679 Archived-At: > From: Kenichi Handa > Cc: eliz@gnu.org, emacs-devel@gnu.org > Date: Tue, 14 Dec 2010 16:44:47 +0900 > > In article , Kenichi Handa writes: > > > In article <83r5dlgg0d.fsf@gnu.org>, Eli Zaretskii 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.