[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberat
bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?
Mon, 22 Dec 2008 12:23:56 +0800
Stefan Monnier <address@hidden> 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.