bug#33567: Syntactic fontification of diff hunks

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: 33567@debbugs.gnu.org
> Date: Tue, 04 Dec 2018 01:36:52 +0200
> 
> > 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", 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.

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

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.  I prefer to rely on
the usual decoding machinery, which we know works well.