bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  34350@debbugs.gnu.org,  vincent.belaiche@gmail.com
> Date: Fri, 08 Feb 2019 16:50:58 -0500
> 
> >> I think intuitively, in terms of encoding for the file's contents the
> >> backends should always return a byte-sequence (i.e. with no-conversion)
> >> and the front-end should then decide how to decode it (e.g., obeying
> >> the -*- coding -*- cookie and such).
> > Why do we need to leave this to the front end?
> 
> So that it's not half-implemented differently in every backend.

But every back-end has its own peculiar ways to do the job.  E.g., Git
needs to call "git ls-files" first, and we then need to read the file
names before calling "git cat".  Other VCSes don't necessarily need
that.  So different implementations cannot be worked around and no
higher layers can even know what the lower layers do to set up
encoding correctly for all of them, at least not in most cases.

> > It's a waste of cycles to do decoding manually in Lisp,
> 
> It'd be better to decode "on the fly" rather than first insert the byte
> stream in a buffer and then decode it.  No doubt.
> But I can't see how to do that and handle -*-coding-*-,
> auto-coding-regexp-alist, and friends.

What do you mean by "how"?  Just do the normal I/O, and all of those
will be taken care of.  Like when we visit a file.  What am I missing?

> > and it also pushes this obscure art to application levels,
> 
> The "front-end" is `vc-find-revision`.

So you are saying that no other VC function cal call the backend's
find-revision method?  But we already have 2 more functions that do
it, and I see no problems with doing that.

> All other code should be layered on top of that one, so it's done at
> only one place.  If that doesn't work (because vc-find-revision is
> not flexible enough) then we should move this decoding code to a
> middle-layer between vc-find-revision and (vc-call find-revision
> ...) that all users of `find-revision` can then use.

I don't think this is possible in general, because different callers
have different needs wrt to encoding/decoding.

> > insist on any encoding, except where the VCS requires it, and it
> 
> I don't know of any VCS that enforces any kind of encoding on the files
> it manages.  AFAIK they pretty much all manage files made of lines where
> the lines are made of bytes (with some extra accommodations for files
> not made of lines).  Some try to handle line-end conversion to
> some extent, but that doesn't really affect us anyway.

You forget VCS operations that return stuff other than the complete
file's contents, like vc-log or vc-dff or calls that return file names
etc.