bug#33567: Syntactic fontification of diff hunks

[Juri Linkov <juri@linkov.net>]

>> > vc-find-revision disables encoding/decoding because it wants to
>> > create an identical copy of the checked-out file, and doesn't want to
>> > be tripped by encoding/decoding issues.  But in your case you don't
>> > write the buffer to a file, so why do you need to bind
>> > coding-system-for-read at all?  I say leave it unbound, and let Emacs
>> > do its job decoding the text as usual.  Does that not work?
>>
>> I tried to remove coding-system-for-read binding from
>> vc-find-revision-no-save, but it still fails to get the buffer
>> in the right encoding.
>
> What is "the right encoding",

By the right encoding I meant the same encoding that is detected
when write-region saves the file, e.g. when using the macro
with-temp-file in vc-find-revision-save.  I don't know how
write-region detects the encoding for the saved file, but we need
the same encoding for the buffer that is not saved to the file
in vc-find-revision-no-save.

> and what did Emacs think the encoding was, when you didn't bind
> coding-system-for-read?  These details are necessary to understand
> what exactly happens there and how to solve it.

vc-git-find-revision binds coding-system-for-read to `binary'.

>> Then I discovered that vc-git-find-revision and also some other VC
>> backend API implementations of find-revision bind
>> coding-system-for-read too.  It seems that removing
>> coding-system-for-read from vc-git-find-revision will cause a lot of
>> breakage.
>
> How do you know vc-git-find-revision doesn't have a subtle bug as
> well, e.g. when file names in the repository are encoded in some
> non-trivial, non-UTF-8 encoding?

This is why vc-git-find-revision does nothing with its output
when it binds coding-system-for-read to `binary',
and doesn't try to encode/decode the git output.

> And anyway, we are not talking about changing vc-git-find-revision or
> affecting it, we are talking about your vc-find-revision-no-save,
> which does a different job.  For the latter, I'd prefer not to decode
> by hand, as that might have subtle issues and will require much more
> testing in all kinds of environments and OSes.

vc-git-find-revision returns the output undecoded.  I don't know
other way to decode it to the default coding other than recode-region.

> I prefer to rely on the usual decoding machinery, which we know
> works well.

Maybe I missed a separate function that can use the decoding machinery
like is used in write-region, but without writing a buffer to the file?