Re: [PATCH] Fix hack-local-variables for find-file-literally with dos encoding

[Tom Gillespie]

> Looking at the existing code here, I think that `subst-char-in-region'
> is wrong in any case, but following the history of that function is
> pretty difficult.  It might have originated here?

I was equally confused, so I left it alone.

> If the intention is to fix up DOS line endings, when it's the wrong
> thing -- it should transform \r\n to \n, not transform any \r anywhere
> in a line to \n...

I agree, what is strange to me is that as far as I can tell it should
be causing a bug by introducing blank lines in the temporary buffer
but somehow is not? I think the reason it is not might be because
subst-char-in-region doesn't actually do anything if the buffer has
dos encoding.

I think we might be able to remove the line entirely?