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

[Vincent Belaïche]

Le 08/02/2019 à 22:50, Stefan Monnier a écrit :
>>> 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

Hello,

Just one simple question : why do we need some specific code in
vc-find-revision to be in charge of selecting the coding scheme and
doing the decoding.

My understanding is that, say for svn backend, what you want to do is
to get the same as

1) svn --non-interactive cat  my_non_ascii_named_file.tex  > temp_file

2) visit temp_file


Instead of doing that redirection into a temporary file, « svn
--non-interactive cat my_non_ascii_named_file.tex » is executed in a
process, and the output is directly inserted into a buffer. Hence the
troubles…

Why not use a temporary file ?

I understand that a temporary file has several drawbacks :

1) it is probably slower, at least for small files,

2) you have to do some clean-up

3) there is a potential security breach to leave tacks on a system file.


Having had a look at find-file lisp code, I noticed that under the hood,
the function insert-file-content is what does the real job of converting
the file bytes to a buffer. Now, looking at the C code of
Finsert_file_contents in fileio.c, I noticed that there is some
provision for not regular files, like pipes.

I was wondering whether there was some intention at some point of time
to use that function in order to recollect in a unified way the output
of a process into a buffer.

Wouldn't that help with our decoding issues ?

  V.