Re: EOL conversion of files in .tar archives

[Eli Zaretskii]

> From: Kenichi Handa <address@hidden>
> CC: address@hidden
> Date: Thu, 24 May 2007 17:15:23 +0900
> 
> > I'm uneasy with that change, because there are other places that use a
> > cons cell as the second argument to find-operation-coding-system, and
> > I'm not sure what you propose is good for them.  For example, mule.el
> > defines a utility function decode-coding-inserted-region that also
> > uses a cons cell.  (This utility function is currently used in
> > jka-compr.el, pcvs.el and url-handlers.el.)  Both it and its users are
> > sufficiently complex that I couldn't easily decide whether the change
> > you suggest will DTRT for them.  Can you help me understand that?
> 
> The docstring of find-operation-coding-system has this
> paragraph.
> 
>   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.  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.

> 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.