From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename Date: Sat, 09 Feb 2019 00:10:38 +0200 Message-ID: <834l9eors1.fsf@gnu.org> References: <84d0o4zoc9.fsf@gmail.com> <83va1vr41l.fsf@gnu.org> <83h8deou6l.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95674"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34350@debbugs.gnu.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 08 23:14:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsEPd-000Ojb-3D for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2019 23:14:21 +0100 Original-Received: from localhost ([127.0.0.1]:35963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEPc-0002eH-1B for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2019 17:14:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsENQ-0001Eo-M1 for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 17:12:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gsENO-0007Ga-NG for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 17:12:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40970) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gsENO-0007GA-Ac for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 17:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gsENN-0001Wz-UH for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 17:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Feb 2019 22:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34350 X-GNU-PR-Package: emacs Original-Received: via spool by 34350-submit@debbugs.gnu.org id=B34350.15496638675820 (code B ref 34350); Fri, 08 Feb 2019 22:12:01 +0000 Original-Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 22:11:07 +0000 Original-Received: from localhost ([127.0.0.1]:40251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsEMV-0001Vn-Fq for submit@debbugs.gnu.org; Fri, 08 Feb 2019 17:11:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsEMS-0001VI-Uc for 34350@debbugs.gnu.org; Fri, 08 Feb 2019 17:11:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEMN-0006uV-Cm; Fri, 08 Feb 2019 17:10:59 -0500 Original-Received: from [176.228.60.248] (port=1490 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gsEMN-0000lL-0W; Fri, 08 Feb 2019 17:10:59 -0500 In-reply-to: (message from Stefan Monnier on Fri, 08 Feb 2019 16:50:58 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:155280 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, 34350@debbugs.gnu.org, vincent.belaiche@gmail.com > 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. But every back-end has its own peculiar ways to do the job. E.g., Git needs to call "git ls-files" first, and we then need to read the file names before calling "git cat". Other VCSes don't necessarily need that. So different implementations cannot be worked around and no higher layers can even know what the lower layers do to set up encoding correctly for all of them, at least not in most cases. > > 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. What do you mean by "how"? Just do the normal I/O, and all of those will be taken care of. Like when we visit a file. What am I missing? > > and it also pushes this obscure art to application levels, > > The "front-end" is `vc-find-revision`. So you are saying that no other VC function cal call the backend's find-revision method? But we already have 2 more functions that do it, and I see no problems with doing that. > 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. I don't think this is possible in general, because different callers have different needs wrt to encoding/decoding. > > 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. You forget VCS operations that return stuff other than the complete file's contents, like vc-log or vc-dff or calls that return file names etc.