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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: vincent.belaiche <at> gmail.com, 34350 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename
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.

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.