Re: EOL conversion of files in .tar archives

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> >   If operation is `insert-file-contents', the argument corresponding to
> >   TARGET may be a cons (FILENAME . BUFFER).  In that case, FILENAME is a
> >   file name to look up, and BUFFER is a buffer that contains the file's
> >   contents (not yet decoded).  If `file-coding-system-alist' specifies a
> >   function to call for FILENAME, that function should examine the
> >   contents of BUFFER instead of reading the file.
> > 
> > So, find-buffer-file-type-coding-system should handle
> > (FILENAME . BUFFER) as described above.

> Well, but it doesn't: it does NOT examine the contents of BUFFER at
> all; it relies on that to be done when it returns undecided.

Ah, for that the docstring should be changed something like
this.

If `file-coding-system-alist' specifies a function to call
for FILENAME, and that function is going to descide the
coding system by examining the contents for decoding, it
should examine the contents of BUFFER instead of reading the
file.

Ummm, a little bit wordy, isn't it?  Could someone make it
more concise?

> And that
> is the reason I asked the question about decode-coding-inserted-region:
> I'm not sure it will look at the region's contents to find the encoding,
> and neither am I sure what should be done in that context, since we
> are inserting only a portion of the buffer.

> So I'd still be happy to know whether your suggestion is not going to
> break decode-coding-inserted-region and its users.

decode-coding-inserted-region itself doesn't detect a coding
system, but internal function decode-coding-region does if
`undecided' is given.

So, the meaning of find-operation-coding-system returning a
not-fully-specified coding system (e.g. undecided, latin-1,
undecided-dos) is to ask decoding routine to detect the
undecided part by the default detection algorithm.

> > That function has this code:
> > 
> >              ;; For any other existing file, decide based on contents.
> >              ((file-exists-p target)
> >               (setq undecided t))
> > 
> > If file-exists-p is used to check whether or not there
> > exists contents that can decide EOL type, isn't it TRT to
> > return undecided in (FILENAME . BUFFER) case.

> It's probably so, but I'm still not sure.  Also, please note that
> returning undecided will cause the text encoding to be detected, not
> only the EOL type.

Is it the problem?  If the file doesn't contain EOL code,
the resulting buffer-file-coding-system doesn't specify EOL
code.  Then, if a user edits it and adds a newline, on
writing, that newline is encoded by the system's detault EOL
code.  On Windows, that is CR LF.

---
Kenichi Handa
address@hidden