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

Message #26 received at 34350 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: vincent.belaiche <at> gmail.com, 34350 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: 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 23:18:42 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>,  34350 <at> debbugs.gnu.org,  vincent.belaiche <at> gmail.com
> Date: Fri, 08 Feb 2019 11:08:36 -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?  It's a waste of cycles
to do decoding manually in Lisp, and it also pushes this obscure art
to application levels, where many Lisp programmers won't know how to
DTRT.

IMO, it's the other way around: by default the back-end should not
insist on any encoding, except where the VCS requires it, and it
should always by default decode the stuff it returns.  The front end
should disable code conversions when needed, and the back-end should
honor that.  This will mostly do TRT, because in the vast majority of
cases users do want eventually to have the stuff decoded, the number
of cases where we want the contrary is minuscule.

VC is just a fancy way of visiting files, so it should normally do the
same, i.e. decode.

Previous Next

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