Re: EOL conversion of files in .tar archives

[Kenichi Handa]

In article <address@hidden>, Chong Yidong <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
> >
> > This solves the problem with the EOL decoding, but reveals a very
> > strange phenomenon: dos-w32.el and dos-w32.elc behave differently.
> > ...
> > -       (set-buffer-file-coding-system coding))
> > +       (set-buffer-file-coding-system last-coding-system-used t))

> What's the rationale for this change?  The purpose of the old code was
> quite transparent; changing it to use last-coding-system-used is not
> obvious, and deserves at least a comment.

I think that change is to fix a bug of original code that
has not been unveiled in non-Windows system.  We have this
code now:

                    (if coding
                        (or (numberp (coding-system-eol-type coding))
                            (vectorp (coding-system-eol-type detected))
                            (setq coding (coding-system-change-eol-conversion
                                          coding
                                          (coding-system-eol-type detected))))
->                    (setq coding
->                          (find-new-buffer-file-coding-system detected)))

In non-Windows system, usually the last two lines are
executed, thus DETECTED is reflected in CODING by
find-new-buffer-file-coding-system.  So,

        (set-buffer-file-coding-system coding)

is ok.  But, if that part is not executed and CODING is
something like undecided-dos, even if decode-coding itself
detects a coding system, the detected one is not reflected
in buffer-file-coding-system.

For instance, even on GNU/Linux, if a tar file contains
a Latin-1 file "temp.dos", and we have this setting,

(push '("\\.dos\\'" . undecided-dos) file-coding-system-alist)

Buffer-file-coding-system of "temp.dos" will be
undecided-dos, instead of latin-1-*.

> (And I think the use of last-coding-system-used leads to
> the "strange phenomenon" mentioned above.)

I think it is very unlikely that it is so.  But...

> All this makes me more dubious about adding this code now.  We should
> either make this entire change conditional on win32 (hedious as the
> resulting code might be) or simply postphone it for Emacs 22.2.

if we are going to include that change in Emacs 22.1, it
seems that making the change conditional is a good idea.

---
Kenichi Handa
address@hidden