Subject: bug#20231: 25.0.50; package.el mangles non-ascii content in downloaded archive-contents data

From: Eli Zaretskii <[email-masked]>
Date: Sat, 11 Apr 2015 22:48:14 +0300

> From: Ivan Shmakov <[email-masked]>
> Date: Sat, 11 Apr 2015 19:30:21 +0000
> 
> >>>>> Eli Zaretskii <[email-masked]> writes:
> 
> […]
> 
>  >> As insert-file-contents may imply a whole lot of additional
>  >> processing beyond decoding UTF-8, I’d rather use an explicit
>  >> decode-coding-region here
> 
>  > Can you explain why?  What additional processing can get in the way?
> 
> 	One of the examples I can readily think of is enriched-decode,
> 	which will automatically be called should there be a
> 	‘Content-Type: text/enriched’ line near the top of the file
> 	being read (per format-alist.)

Yes, but is that kind of processing harmful for the case at point?

Also, are we sure we will never get a compressed file, for example, or
some other binary file?  In those cases, decoding is not TRT.

> 	I have no example at hand of how such processing may be
> 	triggered in practice, but avoiding it altogether seems to me
> 	like a saner approach.

It is also slower.  Again, I have no idea if speed matters in this
case.