Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> >> >  . the file's buffer could be unibyte, in which case you want
>> >> >    insert-file-contents-literally, I think
>> >> We could try to be more careful in this way, indeed.  But AFAIK the only
>> >> risk here is to flag a file as being changed when it hasn't, which is no
>> >> worse than what we currently do (i.e. a false alarm), so I'm not sure
>> >> it's worth the trouble.
>> > The documentation should state this exemption, lest users expect
>> > unibyte buffers to get the same treatment.
>> I don't know for a fact that it doesn't work in the unibyte case, actually.
> buffer-file-coding-system will be the local default,

How do you know?  IOW, which scenario are you thinking about?  I tried
find-file on a PDF file and find-file-literally on a non-ascii text file
and in both cases I get a buffer with buffer-file-coding-system set to
`no-conversion'.  And indeed, in my tests, the code I sent just
correctly detects that the file was not changed.

> so a non-ASCII file will be decoded.

Maybe in some cases it may not work, indeed.  My favorite way to fix
those would be to make sure buffer-file-coding-system is set to
something like `binary' when the buffer is unibyte.


        Stefan