bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?

bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?

[poppyer]

In emacs23, setting a encoding system to nil doesn't behaver the same
as setting it to no-conversion. 
For example: (setq default-process-coding-system '(nil . utf-8))
and (setq default-process-coding-system '(no-conversion . utf-8))
have differenct effects on the following "call-process".
Is this deliberately? is there any good reason?

This setting will break quite a lot of 3rd party .el plugins
(emms/unicad etc), which usually set
xxxxxxxx-default-encoding-system's default value to nil.




In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, NS apple-appkit-949.35)
 of 2008-12-11 on neutron.local
Windowing system distributor `Apple', version 97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: zh_CN.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  erc-log-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  gnus-undo-mode: t
  iswitchb-mode: t
  recentf-mode: t
  which-function-mode: t
  show-paren-mode: t
  mouse-sel-mode: t
  global-hl-line-mode: t
  pinbar-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
RET C-n q C-p C-p C-n C-n ESC g C-p C-p C-p C-p C-p 
C-n C-n C-n C-n C-n C-p C-p C-p C-n C-n ESC g C-p 9 
RET C-n SPC q C-p C-p C-p C-p C-p C-p C-p C-p ESC x 
d e s c r TAB ESC DEL r e DEL DEL b u TAB g TAB ESC 
DEL ESC DEL r e TAB p o TAB r TAB RET

Recent messages:
No more unread newsgroups
Making completion list... [3 times]
Checking spelling of DELIBERATELY...
DELIBERATELY is correct because of root DELIBERATE
Checking spelling of DELIBERATELY...
DELIBERATELY is correct because of root DELIBERATE
Checking spelling of DELIBERATELY...
DELIBERATELY is correct because of root DELIBERATE
Checking spelling of DELIBERATELY...
DELIBERATELY is correct because of root DELIBERATE

bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?

[Stefan Monnier]

> In emacs23, setting a encoding system to nil doesn't behaver the same
> as setting it to no-conversion. 
> For example: (setq default-process-coding-system '(nil . utf-8))
> and (setq default-process-coding-system '(no-conversion . utf-8))
> have differenct effects on the following "call-process".
> Is this deliberately? is there any good reason?

> This setting will break quite a lot of 3rd party .el plugins
> (emms/unicad etc), which usually set
> xxxxxxxx-default-encoding-system's default value to nil.

Why would anybody use nil to mean `binary' aka `no-conversion' aka
`raw-text-unix'?  In this context, nil should simply mean "the coding
system is not specified by this variable, so keep looking for other
clues to figure out which coding system to use".


        Stefan

bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?

[poppyer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In emacs23, setting a encoding system to nil doesn't behaver the same
>> as setting it to no-conversion. 
>> For example: (setq default-process-coding-system '(nil . utf-8))
>> and (setq default-process-coding-system '(no-conversion . utf-8))
>> have differenct effects on the following "call-process".
>> Is this deliberately? is there any good reason?
>
>> This setting will break quite a lot of 3rd party .el plugins
>> (emms/unicad etc), which usually set
>> xxxxxxxx-default-encoding-system's default value to nil.
>
> Why would anybody use nil to mean `binary' aka `no-conversion' aka
> `raw-text-unix'?  In this context, nil should simply mean "the coding
> system is not specified by this variable, so keep looking for other
> clues to figure out which coding system to use".


Sure, no problem for this if the developers decide to do so deliberately.
But we'd better highlight this change in the documents, since it is
different with Emacs22.
It has took me one whole day to figure this "bug" out for emms weirdness.

Cheers,
poppyer
>
>
>         Stefan

bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?

[Stefan Monnier]

> Sure, no problem for this if the developers decide to do so deliberately.
> But we'd better highlight this change in the documents, since it is
> different with Emacs22.
> It has took me one whole day to figure this "bug" out for emms weirdness.

FWIW, I don't know that we've made any change in this respect.
The change in behavior may simply be a side-effect of some changes to
the way we auto-detect encodings.


        Stefan