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
> Date: Sat, 09 Feb 2019 08:12:45 -0500
> 
> > Isn't that sub-optimal design, then?  Those back-ends that can produce
> > a file for a given revision (there are at least 3 of them, AFAIK)
> > should be left to their devices; those which cannot and use some kind
> > of 'cat' command instead can be invoked with output redirected to a
> > file.
> 
> FWIW, I find it cleaner to put the result in a buffer than in a file,
> since with files we have to choose a file name, which implies things
> like race conditions, accessrights/security issues, interaction with
> Tramp, and whatnot.

But vc-find-revision eventually does put it in a file, so ...

> Doesn't insert-file-contents do all the decoding dance done in
> find-file (such as auto-coding-regexp-alist, ...)?

It does (and we call find-file-noselect anyway, not
insert-file-contents).

> > Instead, we invoke the VCS with output redirected to a pipe, slowly
> > read that output from the pipe into a buffer,
> 
> Why should reading from a pipe be slower than from a file?

Because we read in small chunks, and need to enlarge the gap each
time.

> The front-end functions (vc-find-revision-* and vc-default-revert)
> should not bind coding-system-for-read/write and should leave that to
> the backend, since it seems the backends need to do this kind of
> coding-system control more finely.
> 
> > If we decide that back-ends produce undecoded buffers, then vc.el
> > shouldn't be bothered with forcing coding-system-for-read/write at
> > all, right?
> 
> Right.
> 
> > In addition, while I could understand binding of
> > coding-system-for-read in the backend's find-revision (assuming we
> > want the resulting buffer remain undecoded), why should the back-end
> > also bind coding-system-for-write?  I see absolutely no reason for
> > that.  E.g., look at this example:
> 
> I don't see a reason either, other than the coder not being sure which
> of read/write influences which of send/receive, maybe.
> 
> >   (defun vc-hg-find-revision (file rev buffer)
> >     (let ((coding-system-for-read 'binary)
> >       (coding-system-for-write 'binary))
> >       (if rev
> >       (vc-hg-command buffer 0 file "cat" "-r" rev)
> >     (vc-hg-command buffer 0 file "cat"))))
> >
> > Why on earth does this bind coding-system-for-write, when it doesn't
> > write anything at all, it only reads?
> 
> Plain bug, AFAICT.
> 
> > But vc-git.el, for example, uses both in its find-revision
> > implementation.  It therefore must use more complicated juggling with
> > binding the various coding-system variables.  Once again, this is an
> > argument in favor of leaving the encoding/decoding stuff to the
> > back-end.
> 
> Agreed: it should be the backend's responsibility to control the
> encoding/decoding setup in order for the result in the buffer to be
> undecoded bytes (it'd be nice to be able to do it at only one spot
> instead of doing it "by hand" in each and every backend, but IIUC this
> is not an option).

OK, so we basically agree.  I will try to remove the cruft from some
of that, thanks for the feedback.