From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier 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 08:12:45 -0500 Message-ID: References: <84d0o4zoc9.fsf@gmail.com> <83va1vr41l.fsf@gnu.org> <83h8deou6l.fsf@gnu.org> <834l9eors1.fsf@gnu.org> <83o97lnxnl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="182908"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 34350@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 09 14: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 1gsSSZ-000lKr-I0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Feb 2019 14:14:19 +0100 Original-Received: from localhost ([127.0.0.1]:45479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsSSY-0006Aq-JY for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Feb 2019 08:14:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsSRL-0005T5-Gl for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2019 08:13:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gsSRK-000343-Jw for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2019 08:13:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41287) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gsSRK-00033x-GG for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2019 08:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gsSRK-0000uH-Az for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2019 08:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Feb 2019 13:13:02 +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.15497179713464 (code B ref 34350); Sat, 09 Feb 2019 13:13:02 +0000 Original-Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 13:12:51 +0000 Original-Received: from localhost ([127.0.0.1]:40568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsSR8-0000tn-Ku for submit@debbugs.gnu.org; Sat, 09 Feb 2019 08:12:51 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsSR5-0000td-TE for 34350@debbugs.gnu.org; Sat, 09 Feb 2019 08:12:48 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x19DCjCt025031; Sat, 9 Feb 2019 08:12:46 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id BC8A86A380; Sat, 9 Feb 2019 08:12:45 -0500 (EST) In-Reply-To: <83o97lnxnl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Feb 2019 11:01:18 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6479=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6479> : inlines <7014> : streams <1812537> : uri <2793469> 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:155305 Archived-At: >> The `find-revision` backend operation must put the revision's bytes into >> the provided buffer, indeed similarly to when we visit a file. >> But the difference is that in 99% of the cases, the bytes don't come >> from a file but from a process's stdout, so the backed can't directly >> use the "visit a file" trick. > 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. So I think the API seems clean enough. Doesn't insert-file-contents do all the decoding dance done in find-file (such as auto-coding-regexp-alist, ...)? > 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? > then write the resulting buffer to a file. Why? The front-end part may want to do that, but not necessarily. We did that back in the CVS days because it took a long time to extract a particular revision, so this was a way to cache the result. With Git, I find that I basically never want to save the result to a file. >> - vc-find-revision-save >> - vc-find-revision-no-save >> - vc-default-revert >> >> The last one should indeed call the backend directly (as it currently >> does) and should be changed not to bind coding-system-for-read/write and >> instead to assume that the backend deals with bytes. >> >> The other two are begging to be unified to reduce code redundancy and >> are the ones that need the do the file-like decoding (and they indeed do >> it). > > If vc-find-revision and vc-find-revision-no-save need to enforce > no-conversion, then why do most of the back-ends do that as well? 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). Stefan