* bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?
@ 2008-12-21 5:44 poppyer
2008-12-22 2:57 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: poppyer @ 2008-12-21 5:44 UTC (permalink / raw
To: emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?
2008-12-21 5:44 bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately? poppyer
@ 2008-12-22 2:57 ` Stefan Monnier
2008-12-22 4:23 ` poppyer
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2008-12-22 2:57 UTC (permalink / raw
To: poppyer; +Cc: emacs-pretest-bug, 1653
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?
2008-12-22 2:57 ` Stefan Monnier
@ 2008-12-22 4:23 ` poppyer
2008-12-22 12:35 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: poppyer @ 2008-12-22 4:23 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-pretest-bug, 1653
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately?
2008-12-22 4:23 ` poppyer
@ 2008-12-22 12:35 ` Stefan Monnier
0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2008-12-22 12:35 UTC (permalink / raw
To: poppyer; +Cc: emacs-pretest-bug, 1653
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-12-22 12:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-21 5:44 bug#1653: 23.0.60; encoding system nil != no-conversion, is it deliberately? poppyer
2008-12-22 2:57 ` Stefan Monnier
2008-12-22 4:23 ` poppyer
2008-12-22 12:35 ` Stefan Monnier
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.