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

[Stefan Monnier]

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

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

> and it also pushes this obscure art to application levels,

The "front-end" is `vc-find-revision`.  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.

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


        Stefan