Received: (at 34350) by debbugs.gnu.org; 11 Feb 2019 22:00:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 11 17:00:13 2019
Received: from localhost ([127.0.0.1]:44184 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gtJcb-0006t5-5i
for submit <at> debbugs.gnu.org; Mon, 11 Feb 2019 17:00:13 -0500
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57697)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gtJcY-0006ss-FV
for 34350 <at> debbugs.gnu.org; Mon, 11 Feb 2019 17:00:11 -0500
Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca
[132.204.27.242])
by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1BM08G6013696;
Mon, 11 Feb 2019 17:00:08 -0500
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id 8FA07AE145; Mon, 11 Feb 2019 17:00:08 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Vincent =?windows-1252?Q?Bela=EFche?= <vincent.belaiche@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwvy36mng47.fsf-monnier+emacsbugs@HIDDEN>
References: <84r2cec99n.fsf@HIDDEN>
Date: Mon, 11 Feb 2019 17:00:08 -0500
In-Reply-To: <84r2cec99n.fsf@HIDDEN> ("Vincent =?windows-1252?Q?Bela=EF?=
=?windows-1252?Q?che=22's?= message of "Mon,
11 Feb 2019 22:20:20 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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, RV6480=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6480> : inlines <7015> : streams
<1812763> : uri <2794793>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 34350
Cc: Eli Zaretskii <eliz@HIDDEN>, 34350 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 1) svn --non-interactive cat my_non_ascii_named_file.tex > temp_file
[...]
> Why not use a temporary file=A0?
It comes with its own drawbacks (some of which I mentioned in another
message in this thread).
> 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.
I don't think there is.
> Wouldn't that help with our decoding issues ?
Maybe it would, but I think it'd require some non-trivial changes.
Stefan
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 11 Feb 2019 21:20:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 11 16:20:33 2019 Received: from localhost ([127.0.0.1]:44160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gtJ0D-0005ou-1l for submit <at> debbugs.gnu.org; Mon, 11 Feb 2019 16:20:33 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:45191) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <vincent.belaiche@HIDDEN>) id 1gtJ0A-0005og-Lq for 34350 <at> debbugs.gnu.org; Mon, 11 Feb 2019 16:20:31 -0500 Received: by mail-wr1-f45.google.com with SMTP id w17so334182wrn.12 for <34350 <at> debbugs.gnu.org>; Mon, 11 Feb 2019 13:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:mime-version :content-transfer-encoding; bh=tBcOlCjyW2QIKSU3469hH7/m0Jr8+mZacjFexRbOC6U=; b=pzjzyCStZNSxuJ8s9X1aSMyxyk56jPfEKA2/kzmGBsP+biiei9PxhYtBzcCduBg2QC M84F1NMSIb3VOGVi/oDWeH8+DOuJK1QlZOz4MJ5A/HSqMST1EizhVJXF4qFsgWtgkXXn 9o/pypQoMJD1UJU8yKjZCRNuedwBcXH+LLGG6wJfd88KFn76phqZPL6ILbomDk5mIskZ 7c8/SPgwXJPOws/Vza56Zdn/kFt8kYpkrIzrO5Izpw4W+REQ7wgpxAJg4BWj+MZL7hYp H1smqbp3p6cZK3DsYNEYPDaM80CHieb5r6TqFmeAAICYVbEK/OBrnSfCikPj/BPj/miT i5qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-transfer-encoding; bh=tBcOlCjyW2QIKSU3469hH7/m0Jr8+mZacjFexRbOC6U=; b=Vy5TpC1I0jSHKaqWEydYTagI3HFLJci4JT61S4Z2IvhDa8sLBIIUnQwCS13bPaxM1B 0pD0ZvVoWfVeCCSeTBDBwVtgWO04Yi0KPEWUNgQLLczKkKv+xwalYb3xW5ywsR5MCpHF cDL3Nz19FlzqJNbivoDLaK0tiqivs9BS2VPon5koprm34W0YGwGrrAwEXiG6oAE7pxXz XwywAqbSav0z5c4BLtgQPVzyE16tXzjne0+FQxIacGDkU49fkjeT3lR1/oCmGTM4m+NK G8uKTZIcRw5TXtJZQ2ylHLlLvHpAXduXxL4kca5KvcSMlnkXA/DOMAdBrWTEKaBoLhf9 mlzg== X-Gm-Message-State: AHQUAuZKU9Zae0eEyrHJ+tFW9S+M1UACOq9tmHEjSXL5T20UKALJpJVQ qYQb+Puq6togLkcdxZ8P51M= X-Google-Smtp-Source: AHgI3Ibct1P+LCIlRojEZNLE8geAAdjJTAnzr+uRIrY7dTWah0i5Zwcft1hwhrKrahztrc1eGuVe1w== X-Received: by 2002:a5d:5552:: with SMTP id g18mr189762wrw.9.1549920022705; Mon, 11 Feb 2019 13:20:22 -0800 (PST) Received: from AigleRoyal (arennes-656-1-27-51.w86-214.abo.wanadoo.fr. [86.214.222.51]) by smtp.gmail.com with ESMTPSA id u14sm291867wmf.38.2019.02.11.13.20.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 13:20:21 -0800 (PST) From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN> To: monnier@HIDDEN Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename In-Reply-To: <jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> Date: Mon, 11 Feb 2019 22:20:20 +0100 Message-ID: <84r2cec99n.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: Eli Zaretskii <eliz@HIDDEN>, 34350 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Le 08/02/2019 =C3=A0 22:50, Stefan Monnier a =C3=A9crit : >>> 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=C2=A0: 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, =C2=AB=C2=A0svn --non-interactive cat my_non_ascii_named_file.tex=C2=A0=C2=BB is executed i= n a process, and the output is directly inserted into a buffer. Hence the troubles=E2=80=A6 Why not use a temporary file=C2=A0? I understand that a temporary file has several drawbacks=C2=A0: 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.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 10 Feb 2019 19:52:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 10 14:52:53 2019 Received: from localhost ([127.0.0.1]:42801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsv9p-0001m8-1D for submit <at> debbugs.gnu.org; Sun, 10 Feb 2019 14:52:53 -0500 Received: from mail-wm1-f52.google.com ([209.85.128.52]:37562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <vincent.belaiche@HIDDEN>) id 1gsv9n-0001lv-3g for 34350 <at> debbugs.gnu.org; Sun, 10 Feb 2019 14:52:51 -0500 Received: by mail-wm1-f52.google.com with SMTP id x10so7595453wmg.2 for <34350 <at> debbugs.gnu.org>; Sun, 10 Feb 2019 11:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:mime-version :content-transfer-encoding; bh=TfG4q1Vv7LPkeeaJwHJ4WFoeG+hu7Pd5VSdL97mWUCc=; b=HxE3bGO9kCxr6T6lPwu530cu+izPcuULFJy05l6t6MuOmimW4DVc8JkbTi+XOZO4FJ I7M7F6oCP37AJhX2IKcjhN1akbTdXPOFtEZQRt2enhtr+j2555QPIYSWQrunOaKG6eca rQrJmvJ9/lNndKJ3Fx2CqR5q96gedw2xGpHBjWZTP108LrgNGUmkzzXKnkr7y44asMG/ s/bwBoavJlwzX1pT+Ak/X1Ruh1jbKVazXqRfsBHqsQd/SeYSd85iuuMY0yUOhafR99E1 2qA1mFLAUIykroEYrx7N+T1238sh3T9XDiH86p9kqKP4E76uCfxXMPb1iRgZTGgFXCeH vC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-transfer-encoding; bh=TfG4q1Vv7LPkeeaJwHJ4WFoeG+hu7Pd5VSdL97mWUCc=; b=E3YlmpYiQJZ+LUPG8wA8rCi7V7JnDd3/VdW4dBjByTdZl5R/zeNAEQzmX7NbxjTcU5 0zH8wN5/6iAe36iwg0MSqD7MXbu2FErgreWgcKQ8liWVLgbmiHtyZGy2DaedTrJajepc FRnhtRPve73sqEt7+KDjeRpFajzF4aTwAJamq0Wda8PwT6X8d8cBt8xEyaihu6Ry7gi3 U9/g/iEd73c+Y5Hn1ZsihFxOcxEJEbiNMvM88kWeAjK78uZh6dErk9WJRAUoe3QANuk1 JddL7Vi8deg+FguRKAQGGxQoAeVVhtHEc/Ipat+LB/qV2FkWZWlgsixSIDJvdMkrJ87/ sZwA== X-Gm-Message-State: AHQUAubu97OdQddlXFtRw9NoxyTkbCmE53PIHZKK2kqZJX6uTRZZdSWn u1Ev/BxvigUjYCPNF1dAF2c= X-Google-Smtp-Source: AHgI3IZ7hvw6Y50uNRvyeSkdDuDrTbZwpRrt+LQ45WmlutvsJP0w2lKwH3UKvLXvT76GUBxnTdoX6Q== X-Received: by 2002:adf:ec41:: with SMTP id w1mr76138wrn.184.1549828364985; Sun, 10 Feb 2019 11:52:44 -0800 (PST) Received: from AIGLEROYAL (arennes-656-1-27-51.w86-214.abo.wanadoo.fr. [86.214.222.51]) by smtp.gmail.com with ESMTPSA id z3sm11589027wmi.32.2019.02.10.11.52.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Feb 2019 11:52:44 -0800 (PST) From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename In-Reply-To: <3ba3acdb-88bf-7fb2-97e0-ff1038df2cde@HIDDEN> Date: Sun, 10 Feb 2019 20:52:40 +0100 Message-ID: <84sgwvctfb.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Le 09/02/2019 =C3=A0 08:58, Dmitry Gutov a =C3=A9crit : > On 09.02.2019 00:45, Eli Zaretskii wrote: >> How is vc-annotate relevant to vc-git-find-revision and the issue at >> hand? > > It's an investigation tool. > >> coding-system-for-write affects both I/O from and to a subprocess and >> the encoding of the command-line arguments we pass to that >> subprocess. > > Aren't there any programs that expect one encoding for their > arguments, yet output contents in other encodings sometimes? Yes there are. For instance if you edit a document with LaTeX and use pdflatex + koi8 for the encoding, then all the compilation error messages showing the error messages interleaved with pieces of text will be a byte stream where the pieces of text will correspond to characteters coded in koi8. But they are also interleaved with filenames which are also a byte stream which correspond to characters encoded with some encoding depending on the filesystem, for instance that will be utf8 for an MSW-10 machine as it seems that my pdflatex port (MiKTeX) has them in this format =E2=80=94 for filenames all in ASCII that will just make no difference because both utf8 & koi8 are supersets of ASCII. Internally, AFAIK MSW10 uses UTF16, I speculate that my pdflatex port to MSW uses UTF16 wchar_t to access the files and does some utf8/utf16 encoding/decoding w.r.t to input/output with tex source code/tex log. Of course users will want to have the log shown with character decoding using koi8, so that the pieces of text in the log are understandable, so that will mess-up the non-ASCII filenames, for instance if the filename is =C2=AB=C2=A0=D0=9C=D0=B0=D0=BA=D1=80=D0=BE=D0=BD=E2=80=94=D0=A3=D0=B7=D1= =83=D1=80=D0=BF=D0=B0=D1=82=D0=BE=D1=80.tex=C2=A0=C2=BB , it will show out = like =C2=AB=C2=A0=D0=BF=C2=B0=D0=BF=E2=95=9F=D0=BF=E2=95=A8=D1=8F=E2=94=80=D0=BF= =E2=95=AC=D0=BF=E2=95=AB=D0=91=E2=94=80=E2=96=A0=D0=BF=D1=91=D0=BF=E2=95=A5= =D1=8F=E2=94=90=D1=8F=E2=94=80=D0=BF=C2=A9=D0=BF=E2=95=9F=D1=8F=E2=94=8C=D0= =BF=E2=95=AC=D1=8F=E2=94=80.tex=C2=A0=C2=BB in the log, and AUCTeX won't be able to jump at the error line when you do =C2=AB=C2=A0M-g n=C2=A0=C2=BB= =E2=80=94 maybe someday I submit some contribution for AUCTeX to be configurable to decode the filenames, or maybe by that time I simply use xelatex and everything is in utf8 :-/ On the other hand the pdflatex command will accept arguments encoded in whatever the OS requires =E2=80=94 I don't know what my pdflatex port inter= nally does, probably it has some =C2=AB=C2=A0int wmain(int ac, wchar_t const* av[= ])=C2=A0=C2=BB prototype and does some utf16/utf8 encoding of the command line args in order to get a byte stream. So, still under MSW, if my pdflatex is launched from a powershell window, filenames and any arguments are passed to the command as wide chars with utf16 encoding and pdflatex. So if the filename is =E2=84=961.tex, and I type from a powershell prompt: pdflatex =E2=84=961.tex that will work fine =E2=80=94 provided that the file exists =E2=80=94 becau= se, although the character =C2=AB=C2=A0=E2=84=96=C2=A0=C2=BB does not exist in window125= 2, both powershell and my pdflatex port use utf16. Now, if I try the same command from a cmd prompt, funnilly that also will work =E2=80=94 however a DOS .bat file encoded in utf-8 with the same command, even if you launch cmd with /U option=E2=80=A6 But if now I try this command from Emacs (with =C2=AB=C2=A0M-x compile=C2= =A0=C2=BB, or =C2=AB=C2=A0M-&=C2=A0=C2=BB, or directly by eval of =C2=AB=C2=A0(call-proce= ss "pdflatex" nil t nil "=E2=84=961.tex")=C2=A0=C2=BB that will not work either. And that will not = work either from a *shell* buffer using cmdproxy.exe. This is probably because Emacs uses the standard system call =C2=AB=C2=A0system(=E2=80=A6)=C2=A0=C2=BB fun= ction =E2=80=94 I speculate =E2=80=94 and the latter accepts windows1252 encoded command line, and not the microsoft specific _wsystem one. BTW, I don't know whether _wsystem is ported to MinGW, I would not be surprised if it is not=C2=A0: for instance =C2=AB=C2=A0int main(int ac, wch= ar_t const*av[])=C2=A0=C2=BB prototypes aren't ported to MinGW, they do a linker= error, and one has to resort to GetCommandLineW & CommandLineToArgvW windows API functions. An alternative is 1) to use the powershell quote syntax for the command line + utf16 enocoding, 2) to base-64 encode the command line, and 3) pass the encoded block to powershell with the -EncodedCommand option through the usual system(=E2=80=A6) call. So, to summarise : 1. encoding of filenames, encoding of command line, and encoding of file content are 3 different things. So, it is a bit surprising if coding-system-for-write affects all of them in the same way. 2. filename encoding may be different on the command line and on the input/output streams (e.g. pdflatex called from powershell has utf16 on the command line, and utf8 in the files for filenames. 3. filename/argument encoding depends on the command (under MSW, some commands have =C2=AB=C2=A0int main(int ac, char const*av[])=C2=A0=C2=BB = under the hood and as such they expect arguments to be windows1252 encoded =E2=80=94 in Western Europe =E2=80=94 other have =C2=AB=C2=A0int main(int ac, wchar_t= const*av[])=C2=A0=C2=BB under the hood and as such they expect utf16 encoded arguments. So with the first type of command you can have =C2=AB=C2=A0=C5=93=C2=A0=C2= =BB but not =C2=AB=C2=A0=E2=84=96=C2=A0=C2=BB in the arguments, while with the second type you can have both of them. V.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 14:03:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 09:03:14 2019
Received: from localhost ([127.0.0.1]:40602 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gsTDu-000272-8s
for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 09:03:14 -0500
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38218)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gsTDq-00026s-2t
for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 09:03:12 -0500
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x19E38K4025623;
Sat, 9 Feb 2019 09:03:08 -0500
Received: by pastel.home (Postfix, from userid 20848)
id 2ABD96A380; Sat, 9 Feb 2019 09:03:08 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwvsgwxxe2h.fsf-monnier+emacsbugs@HIDDEN>
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
<jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN>
<jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> <834l9eors1.fsf@HIDDEN>
<jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN> <83o97lnxnl.fsf@HIDDEN>
<jwv4l9dyv8e.fsf-monnier+emacsbugs@HIDDEN> <83d0o1nkmu.fsf@HIDDEN>
Date: Sat, 09 Feb 2019 09:03:08 -0500
In-Reply-To: <83d0o1nkmu.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 09 Feb
2019 15:42:33 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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
<1812540> : uri <2793488>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 34350
Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Why should reading from a pipe be slower than from a file?
> Because we read in small chunks,
I understand that what we currently do, but is it really inevitable?
I know you can't transfer an arbitrarily large text with a single `write`
at one end of a pipe and a single `read` at the other (contrary to what
happens with files), but it should be possible to use chunks large
enough that the efficiency is comparable.
> and need to enlarge the gap each time.
Yes, this used to be a real problems in set-buffer-multibyte (with O(N=B2)
behavior), but nowadays it should be a relatively small constant factor.
Of course, if needed, we could provide some way for the Elisp code to
"preallocate" space to avoid resizing the buffer too many times.
[ Goes on dreaming about a buffer representation made of a tree of
immutable text-chunks... ]
> OK, so we basically agree. I will try to remove the cruft from some
> of that, thanks for the feedback.
Right. Maybe we could improve the backend API, but that's a side
problem: the real pressing problem is just cruft and should not be too
hard to fix.
Stefan
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 13:43:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 08:43:02 2019 Received: from localhost ([127.0.0.1]:40585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsSuL-0001dG-HI for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 08:43:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gsSuI-0001cu-Rs for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 08:42:59 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gsSuD-00025y-Bd; Sat, 09 Feb 2019 08:42:53 -0500 Received: from [176.228.60.248] (port=3649 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1gsSuC-0004bd-Ms; Sat, 09 Feb 2019 08:42:53 -0500 Date: Sat, 09 Feb 2019 15:42:33 +0200 Message-Id: <83d0o1nkmu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-reply-to: <jwv4l9dyv8e.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan Monnier on Sat, 09 Feb 2019 08:12:45 -0500) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN> <jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> <834l9eors1.fsf@HIDDEN> <jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN> <83o97lnxnl.fsf@HIDDEN> <jwv4l9dyv8e.fsf-monnier+emacsbugs@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dgutov@HIDDEN, 34350 <at> debbugs.gnu.org > Date: Sat, 09 Feb 2019 08:12:45 -0500 > > > 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. But vc-find-revision eventually does put it in a file, so ... > Doesn't insert-file-contents do all the decoding dance done in > find-file (such as auto-coding-regexp-alist, ...)? It does (and we call find-file-noselect anyway, not insert-file-contents). > > 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? Because we read in small chunks, and need to enlarge the gap each time. > 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). OK, so we basically agree. I will try to remove the cruft from some of that, thanks for the feedback.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 13:12:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 08:12:51 2019
Received: from localhost ([127.0.0.1]:40568 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gsSR8-0000tn-Ku
for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 08:12:51 -0500
Received: from chene.dit.umontreal.ca ([132.204.246.20]:39249)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gsSR5-0000td-TE
for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 08:12:48 -0500
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
Received: by pastel.home (Postfix, from userid 20848)
id BC8A86A380; Sat, 9 Feb 2019 08:12:45 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwv4l9dyv8e.fsf-monnier+emacsbugs@HIDDEN>
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
<jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN>
<jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> <834l9eors1.fsf@HIDDEN>
<jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN> <83o97lnxnl.fsf@HIDDEN>
Date: Sat, 09 Feb 2019 08:12:45 -0500
In-Reply-To: <83o97lnxnl.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 09 Feb
2019 11:01:18 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 34350
Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> 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
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 09:01:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 04:01:53 2019
Received: from localhost ([127.0.0.1]:40450 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gsOWH-0001Ao-2i
for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 04:01:53 -0500
Received: from eggs.gnu.org ([209.51.188.92]:49597)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1gsOWF-0001Ab-9D
for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 04:01:51 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48294)
by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
id 1gsOW6-0003eY-63; Sat, 09 Feb 2019 04:01:44 -0500
Received: from [176.228.60.248] (port=1662 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from <eliz@HIDDEN>)
id 1gsOW4-0004yX-70; Sat, 09 Feb 2019 04:01:40 -0500
Date: Sat, 09 Feb 2019 11:01:18 +0200
Message-Id: <83o97lnxnl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-reply-to: <jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan
Monnier on Fri, 08 Feb 2019 18:03:49 -0500)
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
<jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN>
<jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> <834l9eors1.fsf@HIDDEN>
<jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 34350
Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: dgutov@HIDDEN, 34350 <at> debbugs.gnu.org
> Date: Fri, 08 Feb 2019 18:03:49 -0500
>
> >> > 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?
>
> 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. This should be lightning-fast with most (all?) VCSes. Instead,
we invoke the VCS with output redirected to a pipe, slowly read that
output from the pipe into a buffer, then write the resulting buffer to
a file. Why?
> - 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? 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? This duplication is a large part of the problem here.
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:
(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?
> > 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.
>
> Not really forgetting, no. Instead I was talking specifically about
> things like `find-revision` (i.e. about the content of files).
> For filenames, commit messages and other metadata the situation is quite
> different, indeed.
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.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 08:24:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 03:24:23 2019 Received: from localhost ([127.0.0.1]:40439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsNvz-0000HL-0O for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 03:24:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gsNvw-0000H8-Cp for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 03:24:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gsNvp-0003Bd-MM; Sat, 09 Feb 2019 03:24:13 -0500 Received: from [176.228.60.248] (port=3330 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1gsNvp-0000xv-1G; Sat, 09 Feb 2019 03:24:13 -0500 Date: Sat, 09 Feb 2019 10:23:52 +0200 Message-Id: <83r2chnzdz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-reply-to: <3ba3acdb-88bf-7fb2-97e0-ff1038df2cde@HIDDEN> (message from Dmitry Gutov on Sat, 9 Feb 2019 10:58:38 +0300) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <622e6df3-fb17-cf8a-a166-23fd1549a6c7@HIDDEN> <838syqosyq.fsf@HIDDEN> <3ba3acdb-88bf-7fb2-97e0-ff1038df2cde@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Cc: 34350 <at> debbugs.gnu.org, monnier@HIDDEN, > vincent.belaiche@HIDDEN > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Sat, 9 Feb 2019 10:58:38 +0300 > > > coding-system-for-write > > affects both I/O from and to a subprocess and the encoding of the > > command-line arguments we pass to that subprocess. > > Aren't there any programs that expect one encoding for their arguments, > yet output contents in other encodings sometimes? It happens, yes. Which is why by default coding-system-for-write is not bound. When you bind it while invoking a subprocess, you need to know what you are doing. If there's a conflict between the two encodings, there are a couple of ways to deal with that. However, in the case in point, my reading of the code indicates that there's no need to bind coding-system-for-write at all. It seems we do that due to some copy/paste habit more than due to a real need. Let's see if I succeed in convincing you and Stefan.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 9 Feb 2019 07:58:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 09 02:58:50 2019 Received: from localhost ([127.0.0.1]:40426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsNXG-00086y-6m for submit <at> debbugs.gnu.org; Sat, 09 Feb 2019 02:58:50 -0500 Received: from mail-lj1-f176.google.com ([209.85.208.176]:43865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1gsNXE-00086k-34 for 34350 <at> debbugs.gnu.org; Sat, 09 Feb 2019 02:58:48 -0500 Received: by mail-lj1-f176.google.com with SMTP id q2-v6so4876023lji.10 for <34350 <at> debbugs.gnu.org>; Fri, 08 Feb 2019 23:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jN0dMz1+z4acSHio+nDY5wLAAxFL5li27b5efiiPwvk=; b=RjcESC8QTRraGz4TOzwBLzX3rSgT6lfsU4NYQFgiJ8UX8JHu9rxG6X3Bg/XWLRnD0g mKeHB064FWnP+Baj25RDVTAydCAHnV99H7JT+9S29i9EV/Mt8H8AYVxxY+RWMX/32fVs /6CoOousekylswyLjEeEXOP2MjnSWolS/lgGpMUkmUJaf27kcCnMLbruFOIi/1SgflZz B418LtpEtKY/bLgMOiCDkVTlY74R9aaM8GWQbTLMJiD1zmjB3tEAI8AKm+Z+MWEjXVac ZGYBngtm512vbEtryC2tTBhkoBA+9+vUu5y04O3Eintqvsl1sh9g8LZjZGoj+qhSKcUu I/CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jN0dMz1+z4acSHio+nDY5wLAAxFL5li27b5efiiPwvk=; b=dh9yKneBOsidbX3HY8kQHH4pnmyeseNbZO5gRTAHHUU3Pc/ZEWNzTAJPjUYGFkkWdg reBBWo8uuQitZMtT1E9rLoG+ZupKkOQWJ4Ra8tOqtQ015ltxPgyQi7M6iQ2abVCQDhbA Swjs1vYcyavPWWAxg2oSbUWDP02NWR49bELmoRfNrcSyk3F3fDHYqjkafhXhtQ/0WMad cOy7eNi2OpdbUhtwVwZinTd+F195GKO9QiQtfndZDwyBX2OtudJlwhjEAVa/hxzv76EE /G9nzR0xo7ChR5B351OxmNVNwpaDsIasj43Td6vRJli2zahYx2QQkW1cgLi0DmgYY9/0 Y4qQ== X-Gm-Message-State: AHQUAuZV5a7eeiTGRiCZfg5fkrJimZG5tTofbfuDWyft7wF+rpmOkV+D ABRUiZtxjr6MuppObU2BZzQ= X-Google-Smtp-Source: AHgI3IaQHBKbtFEOt1VU4PAXuUbLQS8LJ6FU1ASFMNSgUvQPWoPjBG5JRAFe0NC4oVl9wTPR4aEpOw== X-Received: by 2002:a2e:b1ca:: with SMTP id e10-v6mr2393802lja.16.1549699122006; Fri, 08 Feb 2019 23:58:42 -0800 (PST) Received: from [192.168.43.247] ([217.118.78.109]) by smtp.googlemail.com with ESMTPSA id q21-v6sm889809ljc.5.2019.02.08.23.58.39 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 23:58:40 -0800 (PST) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename To: Eli Zaretskii <eliz@HIDDEN> References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <622e6df3-fb17-cf8a-a166-23fd1549a6c7@HIDDEN> <838syqosyq.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <3ba3acdb-88bf-7fb2-97e0-ff1038df2cde@HIDDEN> Date: Sat, 9 Feb 2019 10:58:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: <838syqosyq.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 09.02.2019 00:45, Eli Zaretskii wrote: > How is vc-annotate relevant to vc-git-find-revision and the issue at > hand? It's an investigation tool. > coding-system-for-write > affects both I/O from and to a subprocess and the encoding of the > command-line arguments we pass to that subprocess. Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [217.118.78.109 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.208.176 listed in list.dnswl.org] 0.1 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, monnier@HIDDEN, vincent.belaiche@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.6 (/) On 09.02.2019 00:45, Eli Zaretskii wrote: > How is vc-annotate relevant to vc-git-find-revision and the issue at > hand? It's an investigation tool. > coding-system-for-write > affects both I/O from and to a subprocess and the encoding of the > command-line arguments we pass to that subprocess. Aren't there any programs that expect one encoding for their arguments, yet output contents in other encodings sometimes?
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 23:03:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 18:03:57 2019
Received: from localhost ([127.0.0.1]:40279 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gsFBb-0002zM-Tb
for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 18:03:57 -0500
Received: from chene.dit.umontreal.ca ([132.204.246.20]:34814)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gsFBY-0002zA-LY
for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 18:03:54 -0500
Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242])
by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x18N3nBs002272;
Fri, 8 Feb 2019 18:03:50 -0500
Received: by ceviche.home (Postfix, from userid 20848)
id 7C5BD661CF; Fri, 8 Feb 2019 18:03:49 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwv7ee9uc6o.fsf-monnier+emacsbugs@HIDDEN>
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
<jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN>
<jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> <834l9eors1.fsf@HIDDEN>
Date: Fri, 08 Feb 2019 18:03:49 -0500
In-Reply-To: <834l9eors1.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 09 Feb
2019 00:10:38 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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
<1812481> : uri <2793137>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 34350
Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> >> 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.
Then the front/middle end shouldn't set anything up for the backend, but
the backend still needs to return just undecoded bytes.
>> > 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?
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.
> So you are saying that no other VC function cal call the backend's
> find-revision method?
That's the idea, yes.
> But we already have 2 more functions that do
> it, and I see no problems with doing that.
Then we need an additional middle layer.
>> 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.
Hmm... looking at the code I see 3 places where we call the
`find-revision` backend:
- 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).
> 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.
Not really forgetting, no. Instead I was talking specifically about
things like `find-revision` (i.e. about the content of files).
For filenames, commit messages and other metadata the situation is quite
different, indeed.
Stefan
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 22:11:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 17:11:07 2019 Received: from localhost ([127.0.0.1]:40251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsEMV-0001Vn-Fq for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 17:11:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gsEMS-0001VI-Uc for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 17:11:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gsEMN-0006uV-Cm; Fri, 08 Feb 2019 17:10:59 -0500 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 <eliz@HIDDEN>) id 1gsEMN-0000lL-0W; Fri, 08 Feb 2019 17:10:59 -0500 Date: Sat, 09 Feb 2019 00:10:38 +0200 Message-Id: <834l9eors1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-reply-to: <jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan Monnier on Fri, 08 Feb 2019 16:50:58 -0500) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN> <jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dgutov@HIDDEN, 34350 <at> debbugs.gnu.org, vincent.belaiche@HIDDEN > 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.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 21:51:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 16:51:08 2019
Received: from localhost ([127.0.0.1]:40228 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gsE3A-00011i-JG
for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:51:08 -0500
Received: from alt42.smtp-out.videotron.ca ([23.233.128.29]:4851)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gsE37-00011D-CO
for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:51:06 -0500
Received: from fmsmemgm.homelinux.net ([23.233.195.134]) by Videotron with SMTP
id sE30gdLWWTtxcsE31gyN9C; Fri, 08 Feb 2019 16:51:00 -0500
X-Authority-Analysis: v=2.3 cv=QsxwI26d c=1 sm=1 tr=0
a=xXJ578j8WyTliCxld3/pTA==:117 a=xXJ578j8WyTliCxld3/pTA==:17
a=CFTnQlWoA9kA:10 a=JP3XMwzWV1vfR0xuWJAA:9
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id B1D1CAE80E; Fri, 8 Feb 2019 16:50:58 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwva7j6rmep.fsf-monnier+emacsbugs@HIDDEN>
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
<jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> <83h8deou6l.fsf@HIDDEN>
Date: Fri, 08 Feb 2019 16:50:58 -0500
In-Reply-To: <83h8deou6l.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 08 Feb
2019 23:18:42 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-CMAE-Envelope: MS4wfEqJk+if7BAxg99BLz6DNAd9J/VFoKbji4AdDKZPWPPwfOMHIWlc3le4lsUeK2PINvtcfD/9Fe+z8mwyvG45jfQvIlamX9f0Xa367oyY9x+EVFn1bDeY
h5jspp0jKnbOX8XdgcFeEK6+IvxxjOmwl1WAStrERWHXZ/9BwScDnv1Hmqmq6Z9MzEItuoqXCIgfdGdYohIr1fbwgFRGgdgQGjp5onFczZ5OYvXySulabsPH
vMg4T56A2IGt25slFxGApYVZZqUcSLU3TIP92vmcLQnQTxj852YZnesl5mq2bKkMbJX8OujGtvA1LLLXRkeGpQ==
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 34350
Cc: vincent.belaiche@HIDDEN, 34350 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
>> 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
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 21:45:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 16:45:47 2019 Received: from localhost ([127.0.0.1]:40218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsDxz-00081G-H5 for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:45:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gsDxw-0007ta-VW for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:45:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gsDxd-00080N-0U; Fri, 08 Feb 2019 16:45:29 -0500 Received: from [176.228.60.248] (port=3903 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1gsDxa-0005MV-3o; Fri, 08 Feb 2019 16:45:24 -0500 Date: Fri, 08 Feb 2019 23:45:01 +0200 Message-Id: <838syqosyq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-reply-to: <622e6df3-fb17-cf8a-a166-23fd1549a6c7@HIDDEN> (message from Dmitry Gutov on Fri, 8 Feb 2019 20:25:35 +0300) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <622e6df3-fb17-cf8a-a166-23fd1549a6c7@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, monnier@HIDDEN, vincent.belaiche@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Cc: 34350 <at> debbugs.gnu.org, vincent.belaiche@HIDDEN > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Fri, 8 Feb 2019 20:25:35 +0300 > > On 07.02.2019 18:50, Eli Zaretskii wrote: > > > Any idea why it insists on disabling code-conversions? > > This was well before my time, and the only people I remember messing > with these variables anywhere in VC ever since are you (for > Windows-related fixes) and Michael. So this might require some digging > with vc-annotate. How is vc-annotate relevant to vc-git-find-revision and the issue at hand? The last thing vc-find-revision does is to visit the file written by the back-end, and it visits it normally, with find-file-noselect, which decodes the contents as usual. The problems I see are with forcing no-conversion in the intermediate operations in the back-end, where it extracts the specified version to a buffer. > Also note that this affects two commands: one that returns the file > name, and another, its contents. I'm not sure what encoding 'git > cat-file blob' outputs in. We already have in vc-git a variable that holds that encoding (UTF-8 by default). > > In addition to producing undecoded buffer, these bindings have the > > adverse effect of forcing Emacs not to encode command-line arguments > > we pass to the VCS, which is the immediate cause for the current bug. > > The adverse effect sounds like a separate bug. It's not a bug, it's a documented feature. coding-system-for-write affects both I/O from and to a subprocess and the encoding of the command-line arguments we pass to that subprocess. That's why we should be extra-careful when binding coding-system-for-write around invocations of other programs.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 21:19:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 16:19:13 2019 Received: from localhost ([127.0.0.1]:40193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gsDYH-0006gp-4R for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:19:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gsDYF-0006gd-C2 for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 16:19:11 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gsDY6-0002wK-L8; Fri, 08 Feb 2019 16:19:03 -0500 Received: from [176.228.60.248] (port=2291 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1gsDY6-0001Z6-8O; Fri, 08 Feb 2019 16:19:02 -0500 Date: Fri, 08 Feb 2019 23:18:42 +0200 Message-Id: <83h8deou6l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-reply-to: <jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan Monnier on Fri, 08 Feb 2019 11:08:36 -0500) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> <jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: vincent.belaiche@HIDDEN, 34350 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Dmitry Gutov <dgutov@HIDDEN>, 34350 <at> debbugs.gnu.org, vincent.belaiche@HIDDEN > 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.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 17:25:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 12:25:52 2019 Received: from localhost ([127.0.0.1]:40104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gs9uS-0003RF-40 for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 12:25:52 -0500 Received: from mail-lf1-f42.google.com ([209.85.167.42]:33683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1gs9uM-0003Qt-5z for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 12:25:46 -0500 Received: by mail-lf1-f42.google.com with SMTP id q12so3141084lfm.0 for <34350 <at> debbugs.gnu.org>; Fri, 08 Feb 2019 09:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uFcKu7a2OoIaBE4s0k0XSJrle8ZHetCvDHUemMDqn/U=; b=nbsNWaDEDlY87J5YdNZk0thsj8Ktfofk/PJqinUK8JX9YQPUUbt0cnWmD82ynlAU3S 1evg+4wP1r4sRu8QMDjCjn90vokd6l9/ZxZWpeKjoBljvK7KPdZGDjtHEuKS9toX85dL nESBcPm/fj6EVCURLPJKueRN9XEsHAh9XNnILybFOrc2hgXwZYZc/HULiF82Avr5Esay /6Adb5zghgd91RQIaRYfAqDIStjLoxdT3r/I6udBMYp279LiyZM7fyqZlLWogLslN5Yo eIlnXv7SfhopFMY2e8gTuSFsDSeR9uarkqMDfCBSbqB6lNpXJoP1y4ZOxYGmrzs/vmzr F4dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uFcKu7a2OoIaBE4s0k0XSJrle8ZHetCvDHUemMDqn/U=; b=hQzg0t1z6zIbxYTqGUySk3nLzBTCgmHqRIOc9Z6go518ZkYTGAXmRBmsnbwaAEpFKh B5p3TbETnv3EP+XbHIAA2krkHm1bM6IFdLmfzsFO5OtHjootBaGWAe8nDDkntQ2w5o6v f4jAiuo/Fu/hUp9lNOvFu8kUeBpHymDGj5tEpiZWLG2Zu422e+/NlrAmkLpHG2rz8Acv 9pNStg2CA5ckdUtUal5eg/gFmL4MZ3t8E18Gyq1FttAzGW0w9VQHpzwfzIR5S8Oxr81U pR8bRFmPRiLzsdtYVDdUXxbqFAno/5/OMx4bMg99FPlb+/LIMRavxySb5IFBnNmrfpfE rYmQ== X-Gm-Message-State: AHQUAubuVUalvcn+j+BAbdfe2/+FfbyLD2Lcs9F79rOpzkSv1EEnrYei Qjy4orqfLkD2RIopHQevXao= X-Google-Smtp-Source: AHgI3IakwjT4p1jExPeWyv7FtSqjowJmwi2bfA+hygQT4rivnmbJBtWVW3sL4eHMCl6+NwRwbHcUsA== X-Received: by 2002:a19:d04d:: with SMTP id h74mr13079274lfg.52.1549646738477; Fri, 08 Feb 2019 09:25:38 -0800 (PST) Received: from [192.168.43.247] ([217.118.78.123]) by smtp.googlemail.com with ESMTPSA id r2-v6sm469517lja.78.2019.02.08.09.25.36 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 09:25:37 -0800 (PST) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename To: Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN> References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <622e6df3-fb17-cf8a-a166-23fd1549a6c7@HIDDEN> Date: Fri, 8 Feb 2019 20:25:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: <83va1vr41l.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 07.02.2019 18:50, Eli Zaretskii wrote: > Any idea why it insists on disabling code-conversions? This was well before my time, and the only people I remember messing with these variables anywhere in VC ever since are you (for Windows-related fixes) and Michael. So this might require some digging [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.167.42 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [217.118.78.123 listed in dnsbl.sorbs.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.1 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org, vincent.belaiche@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.6 (/) On 07.02.2019 18:50, Eli Zaretskii wrote: > Any idea why it insists on disabling code-conversions? This was well before my time, and the only people I remember messing with these variables anywhere in VC ever since are you (for Windows-related fixes) and Michael. So this might require some digging with vc-annotate. Also note that this affects two commands: one that returns the file name, and another, its contents. I'm not sure what encoding 'git cat-file blob' outputs in. > In addition to producing undecoded buffer, these bindings have the > adverse effect of forcing Emacs not to encode command-line arguments > we pass to the VCS, which is the immediate cause for the current bug. The adverse effect sounds like a separate bug.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 16:08:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 11:08:47 2019
Received: from localhost ([127.0.0.1]:40064 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gs8ho-0001RT-Oa
for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 11:08:47 -0500
Received: from pmta31.teksavvy.com ([76.10.157.38]:4508)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1gs8hl-0001RE-UL
for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 11:08:43 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FuAACPqF1c/1gXWKdjGgEBAQEBAgEBA?=
=?us-ascii?q?QEHAgEBAQGBZYIEgWqYNIINE5l6DYRsAoMsIjgSAQMBAQEBAQECAgJpKIVMAQQ?=
=?us-ascii?q?BeQULCw0nBwsUGDGFMQisMhoCihaMQxeBf4Qjij8iApE+hW2LbAmSZIFtiE4mA?=
=?us-ascii?q?w+HZ4dJlGiBXSKBVjMaCDCDKIIkGhOOKSSPVAEB?=
X-IPAS-Result: =?us-ascii?q?A2FuAACPqF1c/1gXWKdjGgEBAQEBAgEBAQEHAgEBAQGBZYI?=
=?us-ascii?q?EgWqYNIINE5l6DYRsAoMsIjgSAQMBAQEBAQECAgJpKIVMAQQBeQULCw0nBwsUG?=
=?us-ascii?q?DGFMQisMhoCihaMQxeBf4Qjij8iApE+hW2LbAmSZIFtiE4mAw+HZ4dJlGiBXSK?=
=?us-ascii?q?BVjMaCDCDKIIkGhOOKSSPVAEB?=
X-IronPort-AV: E=Sophos;i="5.58,348,1544504400"; d="scan'208";a="69232417"
Received: from unknown (HELO fmsmemgm.homelinux.net) ([167.88.23.88])
by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
08 Feb 2019 11:08:36 -0500
Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848)
id 1013FAEDAA; Fri, 8 Feb 2019 11:08:36 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Message-ID: <jwvpns2tgh3.fsf-monnier+emacsbugs@HIDDEN>
References: <84d0o4zoc9.fsf@HIDDEN> <83va1vr41l.fsf@HIDDEN>
Date: Fri, 08 Feb 2019 11:08:36 -0500
In-Reply-To: <83va1vr41l.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 07 Feb
2019 17:50:30 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 34350
Cc: vincent.belaiche@HIDDEN, 34350 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
> I think there's a real mess regarding encoding and decoding stuff in
> vc-find-revision and its backend implementations.
I can believe it.
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).
But since that holds for all backends, ideally they should be called in
such a way that they automatically return bytes (rather than chars)
without any extra effort (e.g. without manually binding
coding-system-for-read/write).
Stefan
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 8 Feb 2019 07:03:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 08 02:03:16 2019 Received: from localhost ([127.0.0.1]:38827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gs0Bv-0002U8-QY for submit <at> debbugs.gnu.org; Fri, 08 Feb 2019 02:03:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35119) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1gs0Bu-0002Tw-0j for 34350 <at> debbugs.gnu.org; Fri, 08 Feb 2019 02:03:14 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1gs0Bl-0005Fl-Ak; Fri, 08 Feb 2019 02:03:06 -0500 Received: from [176.228.60.248] (port=4088 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1gs0Bh-0002Y4-HR; Fri, 08 Feb 2019 02:03:03 -0500 Date: Fri, 08 Feb 2019 09:02:58 +0200 Message-Id: <83k1iarcd9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Vincent =?iso-8859-15?Q?Bela=EFche?= <vincent.belaiche@HIDDEN> In-reply-to: <84a7j7z12n.fsf@HIDDEN> (message from Vincent =?iso-8859-15?Q?Bela=EFche?= on Thu, 07 Feb 2019 23:27:28 +0100) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84a7j7z12n.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Vincent Belaïche <vincent.belaiche@HIDDEN> > Cc: Vincent Belaïche <vincent.belaiche@HIDDEN> > Date: Thu, 07 Feb 2019 23:27:28 +0100 > > > Is this part relevant? You didn't really think we refuse to support > > non-ASCII file names, did you? > > [...] > > No, I did not, that was just a joke, sorry for not being funny. Oh, that was a joke? Sorry for not catching it. > Concerning your patch, it made it work. Thanks, pushed to the emacs-26 branch. This only fixes some VC backends, there are others which bind coding-system-for-write in their backend implementations, which looks simply wrong to me. I hope we will be able to fix those as well, but perhaps not in Emacs 26.2, if the changes I have in mind will be deemed unsafe.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 7 Feb 2019 22:27:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 07 17:27:39 2019 Received: from localhost ([127.0.0.1]:38673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1grs8x-0004Ss-9H for submit <at> debbugs.gnu.org; Thu, 07 Feb 2019 17:27:39 -0500 Received: from mail-wm1-f47.google.com ([209.85.128.47]:33597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <vincent.belaiche@HIDDEN>) id 1grs8u-0004Sc-Ht for 34350 <at> debbugs.gnu.org; Thu, 07 Feb 2019 17:27:37 -0500 Received: by mail-wm1-f47.google.com with SMTP id h22so5428397wmb.0 for <34350 <at> debbugs.gnu.org>; Thu, 07 Feb 2019 14:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:mime-version :content-transfer-encoding; bh=bZ68ZJN2Q/X84zBtWtpkC0yAEwz30ug0hOjAyHk6KLU=; b=A9L8lrQhuxfiQNVWHJZ3BK8Z+pQJY7wxl6n1Cv9AfAZH/wb/I4GYzc04Qa6lpZGajH IbeinzQsn1+jZx3qLU7rgZQW/x3AGNi2EV0F8O61h07aivBX3nYTvaA7SBqyLxDQBDa9 U0suqed6PAqHzzQtkQDiXGkDD0VIXKX9NofcT3TM//WHR0ZWxpcRro5AaBdKWBwODQuj cEkP7Ibs9j0XraPhTSMHEw1FXTdMn90rZfSFUfJ2VT7cu7O1Ly0M0rLJjie8V/Mb4ur/ 5qR8quXpaz0+Qr/wQVItN1oTvlCGjaHOz8Q/AbUZtcVsgTUGylDbuU0tI9c8Q3qJE2gd kotA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-transfer-encoding; bh=bZ68ZJN2Q/X84zBtWtpkC0yAEwz30ug0hOjAyHk6KLU=; b=VO5cqKrNtKOBtNNuo4NFHnQDy4CO43sptrwmxmmFNnn8u8y6ixO6sUhfFcLkkP2nOh 5//RDnb6nLsHRWoYlVQF3vAC0/SUR0sWJUn64ZQSaIW7eVGpLDh0q0pIeMvO1gCryr/7 3ldJ4FAS/40t3PA1yhyQGldly2b8aewo/wZXDyEUwrMIYQIhVigV54cNdVV1DKA6s8Ov 7Ezr0KrRuexCUImGvicEIyFAEBwxkKeAiE8EVufWa+WMdQVXJQ8Xg8jN25MxGmlJpw6k I3g/Zlav/wS+MFAZ8r5ma05r5QyWajve8g4TXUUjDQv0xsG6fByZBPsenUicruN4nM2r gKgg== X-Gm-Message-State: AHQUAuY4VU/QqN1b3sUBU2uYTa5AQhtNwe5wwsQi0DMCLTfq3sPbO200 inn+LrfhQm6aBwJnzZ6dWCU= X-Google-Smtp-Source: AHgI3IZOKw6pzFzKFrqqpWqB2UYYmU10BIS+8f/o36/kJGfxsveNGnYdLPDmorIN2/eiB5ns0CXL3g== X-Received: by 2002:a1c:2804:: with SMTP id o4mr9565958wmo.150.1549578450678; Thu, 07 Feb 2019 14:27:30 -0800 (PST) Received: from AigleRoyal (arennes-656-1-27-51.w86-214.abo.wanadoo.fr. [86.214.222.51]) by smtp.gmail.com with ESMTPSA id m14sm205352wrx.59.2019.02.07.14.27.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Feb 2019 14:27:29 -0800 (PST) From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, 34350 <at> debbugs.gnu.org Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename In-Reply-To: <83wombr4fy.fsf@HIDDEN> Date: Thu, 07 Feb 2019 23:27:28 +0100 Message-ID: <84a7j7z12n.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Le 07/02/2019 =E0 16:41, Eli Zaretskii a =E9crit : >> From: Vincent Bela=EFche <vincent.belaiche@HIDDEN> >> Date: Wed, 06 Feb 2019 20:52:38 +0100 >> Cc: Vincent Bela=EFche <vincent.belaiche@HIDDEN> >> [...] > >> OK, I know that some Askese people will probably say something like >> =AB don't use non-ASCII characters in file-names =BB which is IMHO quite= a >> ASCII-centric way of thinking, so just in case, my answer is =AB =CE w= =EEll >> =F9se n=F4n-=C0SC=CE=CE =E7h=E6r=E2ct=E8rs n=E9v=BDrthel=E8ss, because = =CE =E0m mys=E8lf a n=F4n-ASCII >> p=E8rs=F4n ! =BB ;-) > > Is this part relevant? You didn't really think we refuse to support > non-ASCII file names, did you? > [...] No, I did not, that was just a joke, sorry for not being funny. Concerning your patch, it made it work. Vincent.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at 34350) by debbugs.gnu.org; 7 Feb 2019 15:51:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 07 10:51:01 2019
Received: from localhost ([127.0.0.1]:38549 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1grlx6-0002x1-PA
for submit <at> debbugs.gnu.org; Thu, 07 Feb 2019 10:51:01 -0500
Received: from eggs.gnu.org ([209.51.188.92]:41763)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1grlx3-0002wl-8l
for 34350 <at> debbugs.gnu.org; Thu, 07 Feb 2019 10:50:58 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:54114)
by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
id 1grlwj-0003w7-Lo; Thu, 07 Feb 2019 10:50:40 -0500
Received: from [176.228.60.248] (port=3293 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from <eliz@HIDDEN>)
id 1grlwj-0005U4-2B; Thu, 07 Feb 2019 10:50:37 -0500
Date: Thu, 07 Feb 2019 17:50:30 +0200
Message-Id: <83va1vr41l.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <84d0o4zoc9.fsf@HIDDEN> (message from Vincent
=?iso-8859-1?Q?Bela=EFche?= on Wed, 06 Feb 2019 20:52:38 +0100)
Subject: Re: bug#34350: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
References: <84d0o4zoc9.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 34350
Cc: 34350 <at> debbugs.gnu.org, vincent.belaiche@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Stefan, Dmitry, can I have your attention please?
I think there's a real mess regarding encoding and decoding stuff in
vc-find-revision and its backend implementations. For some reason,
several backend implementations bind both coding-system-for-read and
coding-system-for-write to no-conversion when they invoke the VCS to
produce a file at a certain revision. Here's an example from
vc-git.el:
(defun vc-git-find-revision (file rev buffer)
(let* (process-file-side-effects
(coding-system-for-read 'binary)
(coding-system-for-write 'binary)
(fullname
(let ((fn (vc-git--run-command-string
file "ls-files" "-z" "--full-name" "--")))
;; ls-files does not return anything when looking for a
;; revision of a file that has been renamed or removed.
(if (string= fn "")
(file-relative-name file (vc-git-root default-directory))
(substring fn 0 -1)))))
(vc-git-command
buffer 0
nil
"cat-file" "blob" (concat (if rev rev "HEAD") ":" fullname))))
Any idea why it insists on disabling code-conversions?
More generally, the find-revision method is documented as
Fetch revision REV of file FILE and put it into BUFFER.
There's nothing here that hints that the resulting buffer will not
look like any visited file, i.e. after decoding. Am I missing
something?
In addition to producing undecoded buffer, these bindings have the
adverse effect of forcing Emacs not to encode command-line arguments
we pass to the VCS, which is the immediate cause for the current bug.
It is my impression that one of the backends did these bindings for
some reason, and then others simply copy-pasted from it.
I'd like to fix this mess, if possible.
Thanks in advance for any insights.
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.Received: (at 34350) by debbugs.gnu.org; 7 Feb 2019 15:42:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 07 10:42:08 2019 Received: from localhost ([127.0.0.1]:38545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1grloU-0002jz-2J for submit <at> debbugs.gnu.org; Thu, 07 Feb 2019 10:42:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1grloS-0002jU-42 for 34350 <at> debbugs.gnu.org; Thu, 07 Feb 2019 10:42:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1grloM-0006I5-IG; Thu, 07 Feb 2019 10:41:58 -0500 Received: from [176.228.60.248] (port=2767 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1grloM-0004nR-2v; Thu, 07 Feb 2019 10:41:58 -0500 Date: Thu, 07 Feb 2019 17:41:53 +0200 Message-Id: <83wombr4fy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Vincent =?utf-8?Q?Bela=C3=AFche?= <vincent.belaiche@HIDDEN> In-reply-to: <84d0o4zoc9.fsf@HIDDEN> (message from Vincent =?utf-8?Q?Be?= =?utf-8?Q?la=C3=AFche?= on Wed, 06 Feb 2019 20:52:38 +0100) Subject: Re: bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename References: <84d0o4zoc9.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34350 Cc: 34350 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Vincent Belaïche <vincent.belaiche@HIDDEN> > Date: Wed, 06 Feb 2019 20:52:38 +0100 > Cc: Vincent Belaïche <vincent.belaiche@HIDDEN> > > After some debugging, I realized that the whole thing executes with > default-directory set to "c:/blah/blah/blah/ê/trunk/" the following > two commands: > > (process-file "svn" nil t nil "--non-interactive" "status" "-v" "ê.tex") > > and then: > > (process-file "svn" nil t nil "--non-interactive" "cat" "ê.tex") > > The first command works quite fine, but the second one fails, and having > a look info the " *temp*" buffer, I saw that svn angrilly barks with > some error message like this one: > > --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- > svn: warning: W200005: 'C:\blah\blah\blah\\trunk\ª.tex' is not under version control > svn: E200009: Could not cat all targets because some targets are not versioned > svn: E200009: Illegal target for the requested operation > --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- > > looking more carefully at things, and having inspected the C code of > function call-process, I realized that the variable > coding-system-for-write has some importance, and tracing this I realized > that when the first svn command is called the variable > coding-system-for-write is nil, while when the second svn command is > called it is 'no-conversion, which makes it fail. Ouch! There's a real mess in vc-find-revision and its backend implementations wrt encoding and decoding. I will address the general problem separately, but for now please see if the patch below fixes the immediate problem with SVN. > OK, I know that some Askese people will probably say something like > « don't use non-ASCII characters in file-names » which is IMHO quite a > ASCII-centric way of thinking, so just in case, my answer is « Î wîll > ùse nôn-ÀSCÎÎ çhærâctèrs névœrthelèss, because Î à m mysèlf a nôn-ASCII > pèrsôn ! » ;-) Is this part relevant? You didn't really think we refuse to support non-ASCII file names, did you? diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 9925196..326284f 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -1966,10 +1966,13 @@ vc-find-revision (with-current-buffer filebuf (let ((failed t)) (unwind-protect - (let ((coding-system-for-read 'no-conversion) - (coding-system-for-write 'no-conversion)) + (let ((coding-system-for-read 'no-conversion)) (with-temp-file filename (let ((outbuf (current-buffer))) + ;; We will read the backend's output with no + ;; conversions, so we should also save the + ;; temporary file with no encoding conversions. + (setq buffer-file-coding-system 'no-conversion) ;; Change buffer to get local value of ;; vc-checkout-switches. (with-current-buffer filebuf
bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Feb 2019 19:53:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 06 14:53:13 2019
Received: from localhost ([127.0.0.1]:36178 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1grTFw-0004QC-0i
for submit <at> debbugs.gnu.org; Wed, 06 Feb 2019 14:53:13 -0500
Received: from eggs.gnu.org ([209.51.188.92]:51335)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <vincent.belaiche@HIDDEN>) id 1grTFt-0004Pv-FX
for submit <at> debbugs.gnu.org; Wed, 06 Feb 2019 14:53:10 -0500
Received: from lists.gnu.org ([209.51.188.17]:38385)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <vincent.belaiche@HIDDEN>)
id 1grTFo-0006mQ-6N
for submit <at> debbugs.gnu.org; Wed, 06 Feb 2019 14:53:04 -0500
Received: from eggs.gnu.org ([209.51.188.92]:37477)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <vincent.belaiche@HIDDEN>) id 1grTFl-0006KA-E9
for bug-gnu-emacs@HIDDEN; Wed, 06 Feb 2019 14:53:04 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
MIME_CHARSET_FARAWAY autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <vincent.belaiche@HIDDEN>) id 1grTFi-0006kf-4H
for bug-gnu-emacs@HIDDEN; Wed, 06 Feb 2019 14:53:01 -0500
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:51286)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <vincent.belaiche@HIDDEN>)
id 1grTFh-0006k5-Bs
for bug-gnu-emacs@HIDDEN; Wed, 06 Feb 2019 14:52:57 -0500
Received: by mail-wm1-x335.google.com with SMTP id b11so3791808wmj.1
for <bug-gnu-emacs@HIDDEN>; Wed, 06 Feb 2019 11:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:date:message-id:mime-version;
bh=sR8Y/LT0D2V7J72cxm3DbJyCaCW8MRdjST5GV1V8jMQ=;
b=MjF5I9r/6r2g9uaYVKlB1mrZUqrimIetm2ffwNGulo5zMvKFNLlu9IMqXLq0sbXWMN
pZHjkuQERoi39wLpGIeoedn5EITewfFJnkcLWo0/tQW4rjQVeYny0mJkwJ7FsvN7JRds
rntqhlD7btpUpGaxLw6I0rnto+dWIe3P9m8b5y6LfnS7sGVB9n9OwFOFQOO+Obylk7P5
z88VScbjoaqb/nH4GOkeYfpST5AxTFebWgZeCyBaNub0NQDALWGA8HJX5pHRTZSC/z0T
DuiP1sq4MGR5S5tZj5ha0EDvsFCXa77jpazn0v5sFo2bJB4SAkvc7tEC671jU7591w9r
1VQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version;
bh=sR8Y/LT0D2V7J72cxm3DbJyCaCW8MRdjST5GV1V8jMQ=;
b=Ko7i2w3LGMrfgy6f123WiuHt5pJyCfSGqQ8myXXuc4rnIRg948AgbOIDFJW/sveTaS
ai0PRnQC1AY1w/iP8clF24mCeG9fbbp5I3HQwSNxiumX+b4qMl2k2a+9I3oFasqOrKl5
VSGerCKfFXl/ksf/+r+ATnMRoq0oaI+iG2xywxmo6F8B+GKkZmPT4SgOogxFLLSiB2ND
kIDKEtwJG4mqM/vlq2CptmGEm9D6PJHHAubZjq0SSbuPbzv5kk5HBP9PZXtor4IOfZMz
l2gCSk1U/ZloWwlx14jFNghyY2ffr36ZiYbWhR6Yq63ZVT3IVqGEcfqv0bS2HmIvnKBy
Su0w==
X-Gm-Message-State: AHQUAubuFCpVERR6/nLD0VoiVp+ElwxoKOEP0moDcI+0aVmygg6mwYJ9
UOvIRwwa9O+BuT4BW25uzgsJw7bV
X-Google-Smtp-Source: AHgI3IadqcuNvuR4+7KJWsOoQ43jNIXcOpmv89PvXE2pdCAdTKlQA1T2pG0vfTxV9ABNRrFJYJDzOw==
X-Received: by 2002:a1c:ed0b:: with SMTP id l11mr3933620wmh.43.1549482775563;
Wed, 06 Feb 2019 11:52:55 -0800 (PST)
Received: from AigleRoyal (arennes-656-1-27-51.w86-214.abo.wanadoo.fr.
[86.214.222.51])
by smtp.gmail.com with ESMTPSA id x3sm30235661wrd.19.2019.02.06.11.52.53
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Wed, 06 Feb 2019 11:52:54 -0800 (PST)
From: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.0.50;
ediff-revision broken with SVN backend + non ascii chars both in
directory and in filename
Date: Wed, 06 Feb 2019 20:52:38 +0100
Message-ID: <84d0o4zoc9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2a00:1450:4864:20::335
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= <vincent.belaiche@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Emacs experts,
I am trying to do some 'M-x ediff-revision' on a file that is under
version control with svn locally to my MSWindows-10 machine, and that
does not work.
The file path is something like
c:/blah/blah/blah/=EA/trunk/=EA.tex
--=-=-=
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
(well, it is not exactly this exact string, but I presume that makes no
difference for our concern=A1=AD).
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
After some debugging, I realized that the whole thing executes with
default-directory set to "c:/blah/blah/blah/=EA/trunk/" the following
two commands:
(process-file "svn" nil t nil "--non-interactive" "status" "-v" "=EA.tex")
and then:
(process-file "svn" nil t nil "--non-interactive" "cat" "=EA.tex")
The first command works quite fine, but the second one fails, and having
a look info the " *temp*" buffer, I saw that svn angrilly barks with
some error message like this one:
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
svn: warning: W200005: 'C:\blah\blah\blah\\trunk\ª.tex' is not under version control
svn: E200009: Could not cat all targets because some targets are not versioned
svn: E200009: Illegal target for the requested operation
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----
looking more carefully at things, and having inspected the C code of
function call-process, I realized that the variable
coding-system-for-write has some importance, and tracing this I realized
that when the first svn command is called the variable
coding-system-for-write is nil, while when the second svn command is
called it is 'no-conversion, which makes it fail.
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
The problem is that in the vc-find-revision function you have somewhere
this setting=A0:
--=-=-=
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
(let ( =A1=AD (coding-system-for-write 'no-conversion) =A1=AD) =A1=AD)
here is a backtrace where I marked two lines X and Y.
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
Debugger entered--Lisp error: (error "Failed (status 1): svn --non-interact=
ive cat =EA.tex")
signal(error ("Failed (status 1): svn --non-interactive cat =EA.tex"))
error("Failed (%s): %s" "status 1" "svn --non-interactive cat =EA.tex")
(progn (if (eq 32 (aref (buffer-name (current-buffer)) 0)) nil (pop-to-bu=
ffer (current-buffer)) (goto-char (point-min)) (shrink-window-if-larger-tha=
n-buffer)) (error "Failed (%s): %s" (if (integerp status) (format "status %=
d" status) status) full-command))
Y (if (and (not (eq t okstatus)) (or (not (integerp status)) (and okstatus =
(< okstatus status)))) (progn (if (eq 32 (aref (buffer-name (current-buffer=
)) 0)) nil (pop-to-buffer (current-buffer)) (goto-char (point-min)) (shrink=
-window-if-larger-than-buffer)) (error "Failed (%s): %s" (if (integerp stat=
us) (format "status %d" status) status) full-command)))
(if (eq okstatus 'async) (let ((proc (let ((process-connection-type nil))=
(apply 'start-file-process command (current-buffer) command squeezed)))) (=
if vc-command-messages (progn (message "Running in background: %s" full-com=
mand))) (set-process-sentinel proc #'ignore) (set-process-filter proc 'vc-p=
rocess-filter) (setq status proc) (if vc-command-messages (progn (vc-exec-a=
fter #'(lambda nil (let ... ...)))))) (if vc-command-messages (progn (messa=
ge "Running in foreground: %s" full-command))) (let ((buffer-undo-list t)) =
(message "CSFW=3D%S" coding-system-for-write) (message "CS=3D%S" (apply 'fi=
nd-operation-coding-system 'call-process "svn" squeezed)) (message "DIR=3D%=
s" default-directory) (message "SQUEEZED=3D%S" squeezed) (setq status (appl=
y 'process-file command nil t nil squeezed))) (if (and (not (eq t okstatus)=
) (or (not (integerp status)) (and okstatus (< okstatus status)))) (progn (=
if (eq 32 (aref (buffer-name (current-buffer)) 0)) nil (pop-to-buffer (curr=
ent-buffer)) (goto-char (point-min)) (shrink-window-if-larger-than-buffer))=
(error "Failed (%s): %s" (if (integerp status) (format "status %d" status)=
status) full-command))) (if vc-command-messages (progn (message "Done (sta=
tus=3D%d): %s" status full-command))))
(let ((process-environment (cons "LC_MESSAGES=3DC" process-environment)) =
(w32-quote-process-args t)) (if (eq okstatus 'async) (let ((proc (let ((pro=
cess-connection-type nil)) (apply 'start-file-process command (current-buff=
er) command squeezed)))) (if vc-command-messages (progn (message "Running i=
n background: %s" full-command))) (set-process-sentinel proc #'ignore) (set=
-process-filter proc 'vc-process-filter) (setq status proc) (if vc-command-=
messages (progn (vc-exec-after #'(lambda nil ...))))) (if vc-command-messag=
es (progn (message "Running in foreground: %s" full-command))) (let ((buffe=
r-undo-list t)) (message "CSFW=3D%S" coding-system-for-write) (message "CS=
=3D%S" (apply 'find-operation-coding-system 'call-process "svn" squeezed)) =
(message "DIR=3D%s" default-directory) (message "SQUEEZED=3D%S" squeezed) (=
setq status (apply 'process-file command nil t nil squeezed))) (if (and (no=
t (eq t okstatus)) (or (not (integerp status)) (and okstatus (< okstatus st=
atus)))) (progn (if (eq 32 (aref (buffer-name ...) 0)) nil (pop-to-buffer (=
current-buffer)) (goto-char (point-min)) (shrink-window-if-larger-than-buff=
er)) (error "Failed (%s): %s" (if (integerp status) (format "status %d" sta=
tus) status) full-command))) (if vc-command-messages (progn (message "Done =
(status=3D%d): %s" status full-command)))))
(let ((squeezed (remq nil flags)) (inhibit-read-only t) (status 0)) (if f=
iles (progn (setq squeezed (nconc squeezed files)))) (let ((process-environ=
ment (cons "LC_MESSAGES=3DC" process-environment)) (w32-quote-process-args =
t)) (if (eq okstatus 'async) (let ((proc (let (...) (apply ... command ... =
command squeezed)))) (if vc-command-messages (progn (message "Running in ba=
ckground: %s" full-command))) (set-process-sentinel proc #'ignore) (set-pro=
cess-filter proc 'vc-process-filter) (setq status proc) (if vc-command-mess=
ages (progn (vc-exec-after #'...)))) (if vc-command-messages (progn (messag=
e "Running in foreground: %s" full-command))) (let ((buffer-undo-list t)) (=
message "CSFW=3D%S" coding-system-for-write) (message "CS=3D%S" (apply 'fin=
d-operation-coding-system 'call-process "svn" squeezed)) (message "DIR=3D%s=
" default-directory) (message "SQUEEZED=3D%S" squeezed) (setq status (apply=
'process-file command nil t nil squeezed))) (if (and (not (eq t okstatus))=
(or (not (integerp status)) (and okstatus (< okstatus status)))) (progn (i=
f (eq 32 (aref ... 0)) nil (pop-to-buffer (current-buffer)) (goto-char (poi=
nt-min)) (shrink-window-if-larger-than-buffer)) (error "Failed (%s): %s" (i=
f (integerp status) (format "status %d" status) status) full-command))) (if=
vc-command-messages (progn (message "Done (status=3D%d): %s" status full-c=
ommand))))) (vc-exec-after #'(lambda nil (run-hook-with-args 'vc-post-comma=
nd-functions command file-or-list flags))) status)
(save-current-buffer (if (or (eq buffer t) (and (stringp buffer) (string=
=3D (buffer-name) buffer)) (eq buffer (current-buffer))) nil (vc-setup-buff=
er buffer)) (let ((squeezed (remq nil flags)) (inhibit-read-only t) (status=
0)) (if files (progn (setq squeezed (nconc squeezed files)))) (let ((proce=
ss-environment (cons "LC_MESSAGES=3DC" process-environment)) (w32-quote-pro=
cess-args t)) (if (eq okstatus 'async) (let ((proc (let ... ...))) (if vc-c=
ommand-messages (progn (message "Running in background: %s" full-command)))=
(set-process-sentinel proc #'ignore) (set-process-filter proc 'vc-process-=
filter) (setq status proc) (if vc-command-messages (progn (vc-exec-after ..=
.)))) (if vc-command-messages (progn (message "Running in foreground: %s" f=
ull-command))) (let ((buffer-undo-list t)) (message "CSFW=3D%S" coding-syst=
em-for-write) (message "CS=3D%S" (apply 'find-operation-coding-system 'call=
-process "svn" squeezed)) (message "DIR=3D%s" default-directory) (message "=
SQUEEZED=3D%S" squeezed) (setq status (apply 'process-file command nil t ni=
l squeezed))) (if (and (not (eq t okstatus)) (or (not ...) (and okstatus ..=
.))) (progn (if (eq 32 ...) nil (pop-to-buffer ...) (goto-char ...) (shrink=
-window-if-larger-than-buffer)) (error "Failed (%s): %s" (if ... ... status=
) full-command))) (if vc-command-messages (progn (message "Done (status=3D%=
d): %s" status full-command))))) (vc-exec-after #'(lambda nil (run-hook-wit=
h-args 'vc-post-command-functions command file-or-list flags))) status))
(let* ((files (mapcar #'(lambda (f) (file-relative-name (expand-file-name=
f))) (if (listp file-or-list) file-or-list (list file-or-list)))) (message=
-truncate-lines t) (full-command (concat (if (string=3D (substring command =
-1) "\n") (substring command 0 -1) command) " " (vc-delistify flags) " " (v=
c-delistify files)))) (save-current-buffer (if (or (eq buffer t) (and (stri=
ngp buffer) (string=3D (buffer-name) buffer)) (eq buffer (current-buffer)))=
nil (vc-setup-buffer buffer)) (let ((squeezed (remq nil flags)) (inhibit-r=
ead-only t) (status 0)) (if files (progn (setq squeezed (nconc squeezed fil=
es)))) (let ((process-environment (cons "LC_MESSAGES=3DC" process-environme=
nt)) (w32-quote-process-args t)) (if (eq okstatus 'async) (let ((proc ...))=
(if vc-command-messages (progn ...)) (set-process-sentinel proc #'ignore) =
(set-process-filter proc 'vc-process-filter) (setq status proc) (if vc-comm=
and-messages (progn ...))) (if vc-command-messages (progn (message "Running=
in foreground: %s" full-command))) (let ((buffer-undo-list t)) (message "C=
SFW=3D%S" coding-system-for-write) (message "CS=3D%S" (apply ... ... "svn" =
squeezed)) (message "DIR=3D%s" default-directory) (message "SQUEEZED=3D%S" =
squeezed) (setq status (apply ... command nil t nil squeezed))) (if (and (n=
ot ...) (or ... ...)) (progn (if ... nil ... ... ...) (error "Failed (%s): =
%s" ... full-command))) (if vc-command-messages (progn (message "Done (stat=
us=3D%d): %s" status full-command))))) (vc-exec-after #'(lambda nil (run-ho=
ok-with-args 'vc-post-command-functions command file-or-list flags))) statu=
s)))
vc-do-command(#<buffer *temp file*-256291> 0 "svn" "c:/blah/blah/blah/=
=EA/trunk/=EA.tex" "--non-interactive" "cat" nil)
apply(vc-do-command #<buffer *temp file*-256291> 0 "svn" "c:/blah/blah/b=
lah/=EA/trunk/=EA.tex" ("--non-interactive" "cat" nil))
vc-svn-command(#<buffer *temp file*-256291> 0 "c:/blah/blah/blah/=EA/tru=
nk/=EA.tex" "cat" nil)
apply(vc-svn-command #<buffer *temp file*-256291> 0 "c:/blah/blah/blah/=
=EA/trunk/=EA.tex" "cat" nil nil)
(let (process-file-side-effects) (apply 'vc-svn-command buffer 0 file "ca=
t" (and rev (not (string=3D rev "")) (concat "-r" rev)) (vc-switches 'SVN '=
checkout)))
vc-svn-find-revision("c:/blah/blah/blah/=EA/trunk/=EA.tex" nil #<buffer =
*temp file*-256291>)
apply(vc-svn-find-revision ("c:/blah/blah/blah/=EA/trunk/=EA.tex" nil #<b=
uffer *temp file*-256291>))
vc-call-backend(SVN find-revision "c:/blah/blah/blah/=EA/trunk/=EA.tex" n=
il #<buffer *temp file*-256291>)
(if backend (vc-call-backend backend 'find-revision file revision outbuf)=
(vc-call-backend (vc-backend file) 'find-revision file revision outbuf))
(save-current-buffer (set-buffer filebuf) (if backend (vc-call-backend ba=
ckend 'find-revision file revision outbuf) (vc-call-backend (vc-backend fil=
e) 'find-revision file revision outbuf)))
(let ((outbuf (current-buffer))) (save-current-buffer (set-buffer filebuf=
) (if backend (vc-call-backend backend 'find-revision file revision outbuf)=
(vc-call-backend (vc-backend file) 'find-revision file revision outbuf))))
(save-current-buffer (set-buffer temp-buffer) (let ((outbuf (current-buff=
er))) (save-current-buffer (set-buffer filebuf) (if backend (vc-call-backen=
d backend 'find-revision file revision outbuf) (vc-call-backend (vc-backend=
file) 'find-revision file revision outbuf)))))
(prog1 (save-current-buffer (set-buffer temp-buffer) (let ((outbuf (curre=
nt-buffer))) (save-current-buffer (set-buffer filebuf) (if backend (vc-call=
-backend backend 'find-revision file revision outbuf) (vc-call-backend (vc-=
backend file) 'find-revision file revision outbuf))))) (save-current-buffer=
(set-buffer temp-buffer) (write-region nil nil temp-file nil 0)))
(unwind-protect (prog1 (save-current-buffer (set-buffer temp-buffer) (let=
((outbuf (current-buffer))) (save-current-buffer (set-buffer filebuf) (if =
backend (vc-call-backend backend 'find-revision file revision outbuf) (vc-c=
all-backend (vc-backend file) 'find-revision file revision outbuf))))) (sav=
e-current-buffer (set-buffer temp-buffer) (write-region nil nil temp-file n=
il 0))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
(let ((temp-file filename) (temp-buffer (get-buffer-create (generate-new-=
buffer-name " *temp file*")))) (unwind-protect (prog1 (save-current-buffer =
(set-buffer temp-buffer) (let ((outbuf (current-buffer))) (save-current-buf=
fer (set-buffer filebuf) (if backend (vc-call-backend backend ... file revi=
sion outbuf) (vc-call-backend ... ... file revision outbuf))))) (save-curre=
nt-buffer (set-buffer temp-buffer) (write-region nil nil temp-file nil 0)))=
(and (buffer-name temp-buffer) (kill-buffer temp-buffer))))
X (let ((coding-system-for-read 'no-conversion) (coding-system-for-write 'n=
o-conversion)) (let ((temp-file filename) (temp-buffer (get-buffer-create (=
generate-new-buffer-name " *temp file*")))) (unwind-protect (prog1 (save-cu=
rrent-buffer (set-buffer temp-buffer) (let ((outbuf ...)) (save-current-buf=
fer (set-buffer filebuf) (if backend ... ...)))) (save-current-buffer (set-=
buffer temp-buffer) (write-region nil nil temp-file nil 0))) (and (buffer-n=
ame temp-buffer) (kill-buffer temp-buffer)))) (setq failed nil))
(unwind-protect (let ((coding-system-for-read 'no-conversion) (coding-sys=
tem-for-write 'no-conversion)) (let ((temp-file filename) (temp-buffer (get=
-buffer-create (generate-new-buffer-name " *temp file*")))) (unwind-protect=
(prog1 (save-current-buffer (set-buffer temp-buffer) (let (...) (save-curr=
ent-buffer ... ...))) (save-current-buffer (set-buffer temp-buffer) (write-=
region nil nil temp-file nil 0))) (and (buffer-name temp-buffer) (kill-buff=
er temp-buffer)))) (setq failed nil)) (if (and failed (file-exists-p filena=
me)) (progn (delete-file filename))))
(let ((failed t)) (unwind-protect (let ((coding-system-for-read 'no-conve=
rsion) (coding-system-for-write 'no-conversion)) (let ((temp-file filename)=
(temp-buffer (get-buffer-create (generate-new-buffer-name " *temp file*"))=
)) (unwind-protect (prog1 (save-current-buffer (set-buffer temp-buffer) (le=
t ... ...)) (save-current-buffer (set-buffer temp-buffer) (write-region nil=
nil temp-file nil 0))) (and (buffer-name temp-buffer) (kill-buffer temp-bu=
ffer)))) (setq failed nil)) (if (and failed (file-exists-p filename)) (prog=
n (delete-file filename)))))
(save-current-buffer (set-buffer filebuf) (let ((failed t)) (unwind-prote=
ct (let ((coding-system-for-read 'no-conversion) (coding-system-for-write '=
no-conversion)) (let ((temp-file filename) (temp-buffer (get-buffer-create =
...))) (unwind-protect (prog1 (save-current-buffer ... ...) (save-current-b=
uffer ... ...)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))=
(setq failed nil)) (if (and failed (file-exists-p filename)) (progn (delet=
e-file filename))))) (vc-mode-line file))
(if (file-exists-p automatic-backup) (rename-file automatic-backup filena=
me nil) (message "Checking out %s..." filename) (save-current-buffer (set-b=
uffer filebuf) (let ((failed t)) (unwind-protect (let ((coding-system-for-r=
ead 'no-conversion) (coding-system-for-write 'no-conversion)) (let ((temp-f=
ile filename) (temp-buffer ...)) (unwind-protect (prog1 ... ...) (and ... .=
..))) (setq failed nil)) (if (and failed (file-exists-p filename)) (progn (=
delete-file filename))))) (vc-mode-line file)) (message "Checking out %s...=
done" filename))
(if (file-exists-p filename) nil (if (file-exists-p automatic-backup) (re=
name-file automatic-backup filename nil) (message "Checking out %s..." file=
name) (save-current-buffer (set-buffer filebuf) (let ((failed t)) (unwind-p=
rotect (let ((coding-system-for-read ...) (coding-system-for-write ...)) (l=
et (... ...) (unwind-protect ... ...)) (setq failed nil)) (if (and failed (=
file-exists-p filename)) (progn (delete-file filename))))) (vc-mode-line fi=
le)) (message "Checking out %s...done" filename)))
(let ((automatic-backup (vc-version-backup-file-name file revision)) (fil=
ebuf (or (get-file-buffer file) (current-buffer))) (filename (vc-version-ba=
ckup-file-name file revision 'manual))) (if (file-exists-p filename) nil (i=
f (file-exists-p automatic-backup) (rename-file automatic-backup filename n=
il) (message "Checking out %s..." filename) (save-current-buffer (set-buffe=
r filebuf) (let ((failed t)) (unwind-protect (let (... ...) (let ... ...) (=
setq failed nil)) (if (and failed ...) (progn ...)))) (vc-mode-line file)) =
(message "Checking out %s...done" filename))) (let ((result-buf (find-file-=
noselect filename))) (save-current-buffer (set-buffer result-buf) (set (mak=
e-local-variable 'vc-parent-buffer) filebuf)) result-buf))
vc-find-revision("c:/blah/blah/blah/=EA/trunk/=EA.tex" nil)
--=-=-=
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
=A1=AD =A1=AD =A1=AD =A1=AD
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----
On line X coding-system-for-write is set to 'no-conversion.
line Y is shown here in function vc-do-command, where I also marked a
line as Z:
--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
;; Run synchronously
(when vc-command-messages
(message "Running in foreground: %s" full-command))
(let ((buffer-undo-list t))
Z (setq status (apply 'process-file command nil t nil squeezed)))
Y (when (and (not (eq t okstatus))
(or (not (integerp status))
(and okstatus (< okstatus status))))
(unless (eq ?\s (aref (buffer-name (current-buffer)) 0))
(pop-to-buffer (current-buffer))
(goto-char (point-min))
(shrink-window-if-larger-than-buffer))
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----
Line Z is where the svn command are called, and there a function
process-file is called, this function calls in turn function
call-process. Function call-process encodes the arguments when
necessary, but the setting of coding-system-for-write to 'no-conversion
disturbs that, and OUCH, the command line passed to svn is not properly
encoded, so with some reason svn unhappilly barks.
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
OK, I know that some Askese people will probably say something like
=AB=A0don't use non-ASCII characters in file-names=A0=BB which is IMHO quit=
e a
ASCII-centric way of thinking, so just in case, my answer is =AB=A0=CE w=EE=
ll
=F9se n=F4n-=C0SC=CE=CE =E7h=E6r=E2ct=E8rs n=E9v
--=-=-=
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
=BDrthel
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=E8ss, because =CE =E0m mys=E8lf a n=F4n-ASCII
p=E8rs=F4n=A0!=A0=BB ;-)
Vincent.
In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32)
of 2018-08-10 built on AIGLEROYAL
Windowing system distributor 'Microsoft Corp.', version 10.0.17134
Recent messages:
Continuing through this frame
Checking out c:/Users/Vincent/Documents/administration/divers/20181212_je_v=
eux_=EAtre_un_homme_euro/trunk/20181212_je_veux_=EAtre_un_homme_euro.tex.~1=
18~...
Running in foreground: svn --non-interactive cat 20181212_je_veux_=EAtre_u=
n_homme_euro.tex
CSFW=3Dno-conversion
CS=3D(windows-1252 . windows-1252)
DIR=3Dc:/Users/Vincent/Documents/administration/divers/20181212_je_veux_=EA=
tre_un_homme_euro/trunk/
SQUEEZED=3D("--non-interactive" "cat" "20181212_je_veux_=EAtre_un_homme_eur=
o.tex")
Entering debugger...
Mark set
Making completion list...
Configured using:
'configure --prefix=3DC:/Nos_Programmes/GNU/Emacs
PKG_CONFIG_PATH=3D/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
'CFLAGS=3D -Og -g3 -L
C:/Programmes/installation/emacs-install/libXpm-3.5.8/src' 'CPPFLAGS=3D
-DFOR_MSW=3D1 -I
C:/Programmes/installation/emacs-install/libXpm-3.5.8/include -I
C:/Programmes/installation/emacs-install/libXpm-3.5.8/src -L
C:/Programmes/installation/emacs-install/libXpm-3.5.8/src'
PKG_CONFIG=3D/usr/bin/pkg-config.exe'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2
Important settings:
value of $LC_MESSAGES: C
value of $LANG: FRA
locale-coding-system: cp1252
Major mode: Emacs-Lisp
Minor modes in effect:
diff-auto-refine-mode: t
shell-dirtrack-mode: t
TeX-PDF-mode: t
recentf-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs h=
ides c:/Nos_Programmes/GNU/Emacs/share/emacs/27.0.50/lisp/loaddefs
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs h=
ides c:/Programmes/installation/cedet-install/cedet-git/lisp/cedet/loaddefs
Features:
(shadow emacsbug vc-annotate vc-filewise edebug completion find-cmd grep
find-dired pp face-remap ediff-ptch eieio-opt vc-git diff-mode help-fns
radix-tree cl-print debug backtrace ediff-vers ediff-merg ediff-wind
ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff vc-rcs
vc-dir bbdb-com vc reftex-cite reftex-parse texmathp org-rmail org-mhe
org-irc org-info org-gnus nnir gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range gnus-win gnus nnheader org-docview doc-view jka-compr
image-mode org-bibtex bibtex org-bbdb org-w3m org-element org org-macro
org-footnote org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs find-func
cal-tex cal-menu calendar cal-loaddefs misearch multi-isearch
vc-dispatcher vc-svn preview prv-emacs reftex-dcr reftex reftex-loaddefs
reftex-vars tex-bar tex-buf toolbar-x noutline outline font-latex latex
latex-flymake flymake-proc flymake warnings tex-ispell tex-style
tex-mode shell pcomplete latexenc log-edit add-log pcvs pcvs-parse
pcvs-info pcvs-defs pcvs-util ewoc calc-undo calccomp calc-vec calc-aent
calc-alg calc-menu parse-time vc-cvs hl-line balance calc-forms
network-stream nsm mailalias smtpmail qp sort bbdb-message sendmail
mail-extr message rmc puny format-spec rfc822 mml mml-sec epa gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils
gmm-utils mailheader elec-pair edmacro kmacro jdee jdee-wiz jdee-test
jdee-archive memoize jdee-stacktrace jdee-refactor dired-aux dired-x
dired dired-loaddefs jdee-project-file jdee-maven dash jdee-keys
jdee-jdb jdee-java-grammar jdee-which-method jdee-font-lock jdee-issues
jdee-help jdee-gen tempo jdee-find jdee-deps jdee-cygwin jdee-custom
jdee-compile jdee-class jdee-bytecode jdee-bug easy-mmode jdee-dbs
jdee-run jdee-jdk-manager jdee-dbo jdee-widgets jdee-db jdee-open-source
semantic/senator semantic/db-find semantic/db-ref semantic/decorate
pulse jdee-import jdee-complete semantic/idle working fame jdee-parse
jdee-backend jdee-bsh jdee-util arc-mode archive-mode jdee-parse-expr
beanshell thingatpt semantic/sb speedbar sb-image dframe jdee-imenu
semantic/imenu imenu semantic/sort semantic/db-file semantic/adebug
eieio-datadebug data-debug cedet-files semantic/db eieio-base
semantic/java semantic/format ezimage semantic/tag-ls semantic/find
semantic/doc semantic/ctxt semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local jdee-avl-tree avl-tree
generator etags xref project efc eieio-compat jdee-annotations
jdee-abbrev jdee-classpath jdee-files jdee-activator jdee-log executable
cus-edit cus-start cus-load compile comint ansi-color ring cedet cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs browse-url flatland-black-theme calc-misc calc-arith calc-ext
calc calc-loaddefs calc-macs skeleton rx tex-mik tex crm advice
preview-latex auto-loads tex-site bbdb bbdb-site timezone bbdb-loaddefs
template w32utils cl recentf tree-widget wid-edit load-path-to-cedet-svn
time-date mule-util finder-inf package let-alist derived pcase cl-extra
help-mode easymenu url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars seq
byte-opt gv bytecomp byte-compile cconv epg epg-config subr-x
cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)
Memory information:
((conses 16 705712 103613)
(symbols 56 59375 1)
(miscs 48 1904 2148)
(strings 32 161627 7850)
(string-bytes 1 5385398)
(vectors 16 71779)
(vector-slots 8 2019402 40514)
(floats 8 326 902)
(intervals 56 18236 3220)
(buffers 992 66))
--=-=-=--
Vincent Belaïche <vincent.belaiche@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#34350; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.