bug#33567: Syntactic fontification of diff hunks

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 33567@debbugs.gnu.org
> Date: Wed, 05 Dec 2018 01:16:48 +0200
> 
> >> 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'.

I see that vc-hg-find-revision does the same.  Sigh.  I guess the
find-revision API was never meant to process the resulting buffer
normally.  My advice would be to reimplement your
vc-find-revision-no-save function differently, without trying to
piggy-back the fact that vc-find-revision inserts the contents into a
buffer.  That is, let the code write the contents to a temporary file,
like vc-find-revision does, then call insert-file-contents to re-read
that file normally.  It would be slightly less efficient, but I think
the result will be much simpler, so a net win.

If you still want to reuse the literal contents of the file, as
inserted by vc-git-find-revision etc., then you will have to duplicate
what insert-file-contents does internally.  I suggest to look at how
this is done in archive-set-buffer-as-visiting-file.

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

vc-git-find-revision does _something_ with Git's output: it uses the
file name returned by Git.  That file name could have a non-trivial
encoding.

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

See above.