Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 57407) by debbugs.gnu.org; 2 Mar 2025 03:38:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 22:38:55 2025 Received: from localhost ([127.0.0.1]:49152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1toaAI-0003Qy-Lh for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:38:55 -0500 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]:56386) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1toaAG-0003QF-Ja for 57407 <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:38:53 -0500 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e4d50ed90aso3234125a12.0 for <57407 <at> debbugs.gnu.org>; Sat, 01 Mar 2025 19:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740886726; x=1741491526; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=BIXsJ+koD2hia9ADfT4RfJxtCJ93EIsF2M0YtewjvPw=; b=hWwhlbQd3Wa++6Ex1FLtXDknl0+hGTeLnv5XcZ6Nyss8dUW4jfFR7946SYZt9j4EGg l21YwJ/VFlwgz2yOzR1YTO607bRXmd6jRONnQTI+OAiekkMMW8vpQEwavwnfKfrNkJNq +idj+UuihPVlpNKwvx3rz02q2VAvcUsuj66xP/C6qRX/bjgLAmR9HSBdwOvM8s8xeVKh 9knrivltPQyjzPeLJ1R6SD2c8MEBMzLdGQ8qGzS0qEs2o4La89YRt33jILPWvYxctT6u 2a06PwEjYSUTntLNXnxuh0tsZG2HKDBDUIAAxUsTGe/sd4HUjyKcHvBBrgu1Na6Cgikt ZQvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740886726; x=1741491526; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BIXsJ+koD2hia9ADfT4RfJxtCJ93EIsF2M0YtewjvPw=; b=hSykkC7YPmXNNYUwJnO/tsmOCdspJ0clVSArMUJFKosaLQMo5QkkVCuzdEFeaZFvpk 1hFV5tRLKaJmnfB7WT+u+ApPu/OvhdWz7cw10LiUK9Yp7WE+cdrNaCC1Ym49tz8rWtUW Dza0jlS1EG81hUgQY0F6uCr5Axo16sN0BrAFfzWcCcEmZFbd1a3qgTBpb0BPDlQTlxZ6 /M0QR/WAQu4H3c3yzmeuCevJdoGXSNPROK23cZMiviV/Q1JR4p2ISZXF0DUjVyRL45OQ lE+s35D8QoGfb6ZWfl2Hs1+NSFX7y5Dv6LBMeVnhDZNusVEtnFYaxTCyPbx3e3yfzBeT AlWQ== X-Forwarded-Encrypted: i=1; AJvYcCUIZWHJwfKBBPe9O6NHoyDFN/YCscw7XwgSmFqMLNKmNJjofI+IL0rl6vSqwRL+35Jxm//Itg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwwxpXOg+RNvs5LSNnh7kSKWvY0Lk6lonEI8H3dt6bbvyUrBH0c QmLTtQYkJ600HRLn5uwPhHPXPhpxz7BhmT+yE0X/3Ngyxc6stvBZlFk9PNswzLja8dzwqjyxvvt k+iqs3shNFRdfbqAVAN+weHZjCoLRdhv9VCc= X-Gm-Gg: ASbGnctJQisMRph6MAsaIZIKPPQN913E8vSwvCtWPwBfuyZgzCK5cK/HOGvm4nVbpn1 F1v1U31+Jgd7GVSR8AHgylMxCZho+Ly9b34yWeWEopj8HjTYFkNyR4GB6+RcpiD21OloDbDQ/HK O7Nt6Cf9Fhj4FvEDMQjiIEbIpy2Q== X-Google-Smtp-Source: AGHT+IGmNVowkeDfGQGd27qWVtvwPiR4OfEze2ISOm61rn3CAViSUJhMH3zMyBNBNNilTHrqxdtK4a2SskZBSPr/KAM= X-Received: by 2002:a05:6402:210e:b0:5e0:745c:6503 with SMTP id 4fb4d7f45d1cf-5e4d6b764a8mr7329023a12.31.1740886726171; Sat, 01 Mar 2025 19:38:46 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 1 Mar 2025 19:38:45 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CADwFkm=Q-ahpkVodnRi48eZb1THnWYcN15QaA=dyZJNZpQVEoQ@HIDDEN> References: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN> <87lercwb0o.fsf@HIDDEN> <handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org> <87sexkj3ol.fsf@HIDDEN> <CADwFkmnXADA_mMA9g1Z=-8b=X0VicfcLBHCGL9bn4w9PFZ2X7w@HIDDEN> <CAJ3okZ0DuvXjsrxaL9sefQhpssWR+a+pCUraca+r6FibnksWfA@HIDDEN> <CADwFkm=Q-ahpkVodnRi48eZb1THnWYcN15QaA=dyZJNZpQVEoQ@HIDDEN> MIME-Version: 1.0 Date: Sat, 1 Mar 2025 19:38:45 -0800 X-Gm-Features: AQ5f1Jo1C1SF-Pi4fd-zGtoylk4xlH7p1q-gdMMRS6ZUh1TujCQbNDFcwV52NP4 Message-ID: <CADwFkmnxwT2PEpZ1PfUvUcb60cptAuybNWMgPkgFEwH_XdyF+A@HIDDEN> Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogY2xvc2VkIChSZTogYnVnIzU3NDA3OiBbUEFUQ0hdIEhhbmRsZQ==?= =?UTF-8?B?IGVycm9yIG9mIOKAmXZjLXJlZ2lzdGVyZWTigJkp?= To: Simon Tournier <zimon.toutoune@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 57407 Cc: Dmitry Gutov <dmitry@HIDDEN>, 57407 <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 (-) Hi Simon, Stefan Kangas <stefankangas@HIDDEN> writes: > Simon Tournier <zimon.toutoune@HIDDEN> writes: > >> The previous comments appear to me very good ones and they are real >> improvements. I do not promise to implement in timely manner but I >> will do my best to dedicate some time before my summer holidays -- >> always the good time for rushing and cleaning the endless TODO list. >> ;-) > > Sounds good. Please let us know when you have a new patch. Were you able to make any progress here?
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 11 Feb 2025 07:26:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 02:26:49 2025
Received: from localhost ([127.0.0.1]:54003 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thkfQ-0002hF-Dr
for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 02:26:49 -0500
Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:47273)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
id 1thkfO-0002gw-3y
for 57407 <at> debbugs.gnu.org; Tue, 11 Feb 2025 02:26:47 -0500
Received: by mail-ed1-x52e.google.com with SMTP id
4fb4d7f45d1cf-5de4a8b4f86so5916619a12.2
for <57407 <at> debbugs.gnu.org>; Mon, 10 Feb 2025 23:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1739258800; x=1739863600; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=kTiIaRe3BPg6seUPiecxjyrMahhZTfdWgAfStmtdxt8=;
b=Vz7CEMzumMGj3FZSzHLhMGDZOIfsO6Vy0//X2NfudJA5+miLBykOlta7aMO/SF2qzc
Rav2q1u9CsL5+MQEkGEi3fATArEPFxgWtET6fUlqyfCQsvEF6vSRGp0LJb5K7vuuen1O
ZdTR8e8lNuk/klFcJvbGKkXCrcshSNnJbbwwPEMSG7D3yzIoQ08mE8zc4tzhuspd4fA0
q/JBe0V9EVXqIQJbzTilqgYFDJtEgY6JA6fDkGfy+gbNNvtrkva3iQq/8WoB7BuLuON4
f8RXhtzIKAhU7xFVrcInseBksCmfJuGOoNkwH/cPnfKasD/Mu2qPe3DGZeYc2A50otI6
UYPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1739258800; x=1739863600;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:x-gm-message-state:from:to
:cc:subject:date:message-id:reply-to;
bh=kTiIaRe3BPg6seUPiecxjyrMahhZTfdWgAfStmtdxt8=;
b=JglBqFA418bnhDVXNj4L3z87CQASCl/NmODizpbBhM2BqJCF8TeDKp+o4ZLsakcaAV
qKenYAi21FXT5KGOifnVdYjycHlU5rgBy0EGCddt9sJ6rU0Mm7RyxF7keY+tCqJE3Eva
c2X1YchbWutPxrtqP3OHS/K+XKL6bn+oKhCkUxb1PQLt4YIpCRmK8LCBIIsb4avReFrm
3HHKsunNDJmQrHEj49fjZufQMbLl5NlttD3fzZyFx2ukSeGYxS+af7+iIIZlh2Aupasr
oDaBsSsvli7Wt6V+0K3z+NxJ0Kw32i4a7ONLIVdW3wnlBa1Vb52rVPBPCbi4KgMlWP8n
HF8g==
X-Gm-Message-State: AOJu0YzXBPt2lax9ReFYSBK2gudw1N77B8jyL3xw/N4XFyrdxt7yiI5z
WhixtfYb4Hutq7cwJ7RS/XHcOdNkeiotcgaOTd5cCiFkiRllsVU9HzcXmH+3U01pslHlTVBn+t+
C1aMk4C7Fn6DgYqCPfhvsIVj2DTE=
X-Gm-Gg: ASbGnctGyamKbRMi6Gfe+TslFAY1QT0kbe8U1TJ8CC4ZK+XmMxjk5rxEvH/HhB8Upfm
D4GiA3qS4hEA51vvWZRYJf4GF0+LnP8N/4iNV0ZRTZ3Oz44mABWbjNPf1UpfpPB4pKCJ5moKHig
==
X-Google-Smtp-Source: AGHT+IE1BOGefuBrNpogbSWBJB/MpV6u7eBW8KhKV71yyQFZ+bRAzPcNDupAzGZ5XOVKRuT51++sUQGKBv1P8lbBmIc=
X-Received: by 2002:a05:6402:2424:b0:5d3:baa3:29f with SMTP id
4fb4d7f45d1cf-5de450050d5mr16297501a12.9.1739258799595; Mon, 10 Feb 2025
23:26:39 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Mon, 10 Feb 2025 23:26:39 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CADwFkmnNROfD0yzFtkV5nTqawogyH4zJPOQXPQ+SSLJEKsj-ag@HIDDEN>
References: <87lercwb0o.fsf@HIDDEN>
<f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN>
<87czc0eqfn.fsf@HIDDEN> <1529983c-f487-0e27-338e-9c537d2c7169@HIDDEN>
<CADwFkmnNROfD0yzFtkV5nTqawogyH4zJPOQXPQ+SSLJEKsj-ag@HIDDEN>
MIME-Version: 1.0
Date: Mon, 10 Feb 2025 23:26:39 -0800
X-Gm-Features: AWEUYZlKm5QeBkLjcD-O-wEEKjNxC4PGKgumj_njb_5bIOQPMoY4Wb60YW2a_rU
Message-ID: <CADwFkmm71eKgAFPYkQOpY=JoLr-F0GocEJFScYZO7_Cmg3QZWg@HIDDEN>
Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogW1BBVENIXSBIYW5kbGUgZXJyb3Igb2Yg4oCZdmMtcmVnaXN0ZQ==?=
=?UTF-8?B?cmVk4oCZ?=
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 57407
Cc: 57407 <at> debbugs.gnu.org, Simon Tournier <zimon.toutoune@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 Kangas <stefankangas@HIDDEN> writes:
> That was one year ago.
>
> Simon, did you have a chance to look into the issues that Dmitry
> mentioned below?
Friendly ping.
> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> On 12.09.2022 15:18, Simon Tournier wrote:
>>> Hi,
>>> Thanks for your comments.
>>> On lun., 12 sept. 2022 at 04:08, Dmitry Gutov <dgutov@HIDDEN> wrote:
>>>
>>>> Do I take this right that the main purpose of the patch is to have the=
"Error:
>>>> ..." messages replaced with "Warning: ..."?
>>> Somehow yes. More explicitly, replace =E2=80=9CError: <useless message=
>=E2=80=9D with
>>> =E2=80=9CWarning: <more helpful>=E2=80=9D.
>>
>> Sounds good.
>>
>>>> But you also add a bunch of re-signaling code like
>>>>
>>>> + (let ((state (condition-case err
>>>> + (vc-bzr-state-heuristic file)
>>>> + (error (signal (car err) (cdr err))))))
>>>>
>>>> What is the idea behind this? Why not just keep the call?
>>> What do you mean? You need to catch the error and propagates it.
>>
>> Why not just let it bubble up? Why catch it at all here?
>>
>> There is one condition-case that actually does something (in vc-do-comma=
nd), but
>> adding a condition-case with exactly one handler which simply re-throws =
doesn't
>> seem to change anything (except swallowing a part of the backtrace).
>>
>>> If the heuristic fails in vc-bzr-state-heuristic, then =E2=80=99vc-bzr-=
state=E2=80=99 is
>>> called, which itself then calls =E2=80=99vc-bzr-status=E2=80=99. This =
status function
>>> can signal an error and it requires to be raised again.
>>>
>>>> And in vc-svn-registered, for example. You re-signal whatever error is=
caught,
>>>> without any alternative. Do we need the condition-case there at all, t=
hen?
>>> Yes, you need to re-throw the error to propagate it. See
>>> =E2=80=99(elisp)Handling Errors=E2=80=99:
>>> Sometimes it is necessary to re-throw a signal caught by
>>> =E2=80=98condition-case=E2=80=99, for some outer-level handler to=
catch. Here=E2=80=99s
>>> how to do that:
>>> (signal (car err) (cdr err))
>>> where =E2=80=98err=E2=80=99 is the error description variable, th=
e first argument
>>> to =E2=80=98condition-case=E2=80=99 whose error condition you wan=
t to re-throw.
>>> Or I am missing a point. :-)
>>
>> You indeed might end up re-signaling errors this way, but that's only us=
eful if
>> the condition-case form has some other purpose to begin with (aside from
>> re-throwing). Like catching different kinds of errors, logging some one =
way and
>> re-throwing others. Like you do in vc-do-command.
>>
>> If you simply want to stop swallowing the errors in some form, you can j=
ust
>> remove the condition-case form.
>>
>>>> Furthermore, we'll have to examine the resulting effect on the behavio=
r of
>>>> various backend methods. Apparently, up until now vc-svn-registered ne=
ver
>>>> signaled an error (swallowed all of them). And now whatever callers it=
has,
>>>> will need to handle possible errors.
>>> I think it is what this patch is doing: handle possible errors by the
>>> =E2=80=99vc-<backend>-registered=E2=80=99 callers.
>>
>> Have you looked at this comment in vc-svn-registered?
>>
>> ;; Some problem happened. E.g. We can't find an `svn'
>> ;; executable. We used to only catch `file-error' but when
>> ;; the process is run on a remote host via Tramp, the error
>> ;; is only reported via the exit status which is turned into
>> ;; an `error' by vc-do-command.
>>
>> I wonder if that's still true.
>>
>>>> It's probably fine, though. vc-backend is a more popular function, and=
it
>>>> seems not much is changing for it, since, for some reason, vc-refresh-=
state
>>>> wrapped its call in with-demoted-errors anyway.
>>> For what my opinion is worth, the commit
>>> 991e145450ec8b02865597bc80fd797e39e81f07 =E2=80=93 which replaces
>>> =E2=80=99ignore-errors=E2=80=99 with =E2=80=99with-demoted-errors=E2=80=
=99 only for the Git backend =E2=80=93 is
>>> a valuable idea but incorrectly implemented. This patch is an attempt
>>> to improve the situation.
>>>
>>>> But I think we have other callers of it in-tree, and not all of them g=
uard
>>>> with with-demoted-errors or condition-case. What do you think we shoul=
d do
>>>> with them?
>>> Could you be more specific about these =E2=80=9Cother callers=E2=80=9D?=
From my
>>> understanding, =E2=80=99vc-<backend>-registered=E2=80=99 is called by =
=E2=80=99vc-registered=E2=80=99
>>> and this patch handles this case; even =E2=80=99vc-registered=E2=80=99 =
is not modified
>>> by this patch and the handler happens in =E2=80=99vc-refresh-state=E2=
=80=99.
>>
>> vc-registered and vc-dir-recompute-file-state call it.
>>
>> And vc-deduce-fileset-1 calls vc-registered. I suppose some or all of th=
ese
>> should catch errors now?
>>
>>> Moreover,
>>> --8<---------------cut here---------------start------------->8---
>>> $ for backend in svn git hg ;do ag --elisp vc-${backend}-registered ;do=
ne
>>> lisp/ldefs-boot.el
>>> 33455: (defun vc-svn-registered (f)
>>> 33462: (vc-svn-registered f))))
>>> lisp/vc/vc-svn.el
>>> 110:;; vc-svn-registered, but we want the value to be compiled at start=
up, not
>>> 133:;;;###autoload (defun vc-svn-registered (f)
>>> 140:;;;###autoload (vc-svn-registered f))))
>>> 142:(defun vc-svn-registered (file)
>>> 242: (vc-svn-registered file)
>>> lisp/ldefs-boot.el
>>> 33399: (defun vc-git-registered (file)
>>> 33404: (vc-git-registered file))))
>>> lisp/vc/vc-git.el
>>> 244:;;;###autoload (defun vc-git-registered (file)
>>> 249:;;;###autoload (vc-git-registered file))))
>>> 251:(defun vc-git-registered (file)
>>> lisp/ldefs-boot.el
>>> 33410: (defun vc-hg-registered (file)
>>> 33415: (vc-hg-registered file))))
>>> lisp/vc/vc-hg.el
>>> 85:;; vc-hg-registered and vc-hg-state
>>> 198:;;;###autoload (defun vc-hg-registered (file)
>>> 203:;;;###autoload (vc-hg-registered file))))
>>> 206:(defun vc-hg-registered (file)
>>> --8<---------------cut here---------------end--------------->8---
>>> means that another caller is =E2=80=99vc-svn-working-revision=E2=80=99 =
used by,
>>> --8<---------------cut here---------------start------------->8---
>>> (defun vc-working-revision (file &optional backend)
>>> "Return the repository version from which FILE was checked out.
>>> If FILE is not registered, this function always returns nil."
>>> (or (vc-file-getprop file 'vc-working-revision)
>>> (progn
>>> (setq backend (or backend (vc-backend file)))
>>> (when backend
>>> (vc-file-setprop file 'vc-working-revision
>>> (vc-call-backend
>>> backend 'working-revision file))))))
>>> --8<---------------cut here---------------end--------------->8---
>>> Therefore, =E2=80=99vc-svn-working-revision=E2=80=99 should also be gua=
rded with
>>> =E2=80=99condition-case=E2=80=99 and display an appropriate message, in=
deed.
>>>
>>>>> It is probably an abuse of =E2=80=99pcase=E2=80=99. Is =E2=80=99cond=
=E2=80=99 better here? Last,
>>>>> I have not found in the documentation how to differentiate what it is
>>>>> raised depending on the error type, hence the =E2=80=99pcase=E2=80=99=
.
>>>>
>>>> I think you just need to write the specific error type instead of 'err=
or' in
>>>> the handler clause.
>>> Maybe I am missing a point about error handling and how they propagate.
>>> If I consider this change removing =E2=80=99pcase=E2=80=99 and write th=
e specific error
>>> as you are suggesting,
>>> --8<---------------cut here---------------start------------->8---
>>> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
>>> index 778d1139fc..39ad27f2fd 100644
>>> --- a/lisp/vc/vc-dispatcher.el
>>> +++ b/lisp/vc/vc-dispatcher.el
>>> @@ -361,15 +361,13 @@ vc-do-command
>>> (let ((buffer-undo-list t))
>>> (condition-case err
>>> (setq status (apply #'process-file command nil t nil squee=
zed))
>>> - (error
>>> - (pcase (car err)
>>> - ('file-missing
>>> - (if (string=3D (cadr err) "Searching for program")
>>> - ;; The most probable is the lack of the backen=
d binary.
>>> - (signal 'vc-not-supported (cdr err))
>>> - (signal (car err) (cdr err))))
>>> - (_
>>> - (signal (car err) (cdr err)))))))
>>> + ((file-missing
>>> + (if (string=3D (cadr err) "Searching for program")
>>> + ;; The most probable is the lack of the backend =
binary.
>>> + (signal 'vc-not-supported (cdr err))
>>> + (signal (car err) (cdr err))))
>>> + (_
>>> + (signal (car err) (cdr err))))))
>>> (when (and (not (eq t okstatus))
>>> (or (not (integerp status))
>>> (and okstatus (< okstatus status))))
>>> --8<---------------cut here---------------end--------------->8---
>>> then instead of,
>>> --8<---------------cut here---------------start------------->8---
>>> Warning: (vc-not-supported "Searching for program" "No such file or dir=
ectory" "git")
>>> --8<---------------cut here---------------end--------------->8---
>>> the report is,
>>> --8<---------------cut here---------------start------------->8---
>>> VC refresh error: (void-function _)
>>> --8<---------------cut here---------------end--------------->8---
>>
>> _ is syntax specific to pcase. condition-case uses 't' for the fallback =
handler.
>>
>>> Well, I do not know how to avoid the =E2=80=99pcase=E2=80=99 here to co=
rrectly propagate
>>> the errors.
>>> About the other =E2=80=99pcase=E2=80=99, this code,
>>> --8<---------------cut here---------------start------------->8---
>>> ((setq backend (condition-case err
>>> (vc-backend buffer-file-name)
>>> ((vc-not-supported
>>> (message "Warning: %S" err))
>>> (_
>>> (message "VC refresh error: %S" err)))))
>>> --8<---------------cut here---------------end--------------->8---
>>> does not raise the correct message.
>>
>> Does this work for you?
>>
>> ((setq backend (condition-case err
>> (vc-backend buffer-file-name)
>> (vc-not-supported
>> (message "Warning: %S" err))
>> (t
>> (message "VC refresh error: %S" err))))
>>
>> And you can update the previous (more complex) example similarly, withou=
t pcase.
>>
>>> Somehow, I probably miss how to correctly propagate errors but the patc=
h
>>> is, IMHO, the simplest way.
>>>
>>>> Regarding the rest of the patch, could you explain the change in
>>>> vc-bzr-state-heuristic? Looking at the code, I figure the idea was to
>>>> future-proof the parser against some future change in file format, to =
fall
>>>> back to (slower) calling the 'bzr' program. Are we somehow certain now=
this is
>>>> not needed?
>>> Nothing has really changed. The current pattern is:
>>> --8<---------------cut here---------------start------------->8---
>>> (condition-case err
>>> (with-temp-buffer
>>> ...
>>> (if (not (looking-at "#bazaar dirstate flat format 3"))
>>> (vc-bzr-state file) ; Some other unknown format?
>>> (let* ...)))
>>> ;; The dirstate file can't be read, or some other problem.
>>> (error
>>> (message "Falling back on \"slow\" status detection (%S)" err=
)
>>> (vc-bzr-state file)))
>>> --8<---------------cut here---------------end--------------->8---
>>> where it means =E2=80=99vc-bzr-state=E2=80=99 is at two places =E2=80=
=93 which is redundant.
>>> Instead, the pattern,
>>> --8<---------------cut here---------------start------------->8---
>>> (condition-case err
>>> (with-temp-buffer
>>> ...
>>> (if (not (looking-at "#bazaar dirstate flat format 3"))
>>> (signal 'error "VC: Bzr dirstate is not flat format 3"=
)
>>> (let* ...)))
>>> ;; The dirstate file can't be read, or some other problem.
>>> (error
>>> (message "Falling back on \"slow\" status detection (%S)" err=
)
>>> (vc-bzr-state file)))
>>> --8<---------------cut here---------------end--------------->8---
>>> is better because it appears only at one location. Now, knowing if thi=
s
>>> test about the BZR format is relevant or not is another story. :-)
>>
>> Makes sense now, thanks.
>>
>>> The patch is just tweaking how the errors are handled, not the logic
>>> behind. In another patch, this =E2=80=99vc-bzr-state-heuristic=E2=80=
=99 could be split;
>>> as it is done with HG: vc-hg-state calling vc-hg-state-fast falling bac=
k
>>> to vc-hg-state-slow =E2=80=93 instead of having the fast (heuristic) in=
cluded.
>>
>> Up to you.
>>
>>> Let me know how to proceed for helping in the review process.
>>
>> Let's address the raised points first. Thank you.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 18 Jun 2024 21:18:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 18 17:18:52 2024 Received: from localhost ([127.0.0.1]:52419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sJgE8-0001Pu-1a for submit <at> debbugs.gnu.org; Tue, 18 Jun 2024 17:18:52 -0400 Received: from mail-ed1-f47.google.com ([209.85.208.47]:61916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1sJgE7-0001Pd-5P for 57407 <at> debbugs.gnu.org; Tue, 18 Jun 2024 17:18:51 -0400 Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-57c6011d75dso7231562a12.3 for <57407 <at> debbugs.gnu.org>; Tue, 18 Jun 2024 14:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718745462; x=1719350262; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=sfWtmha6AvwTrs0xIGI0QAe+Hy7tn/djEUC/QZKg0sY=; b=iujKf9SYIatwER2aHkKGSvdyHdk2f7Z7rmn337upyK7pN6axr9o0li9MpMQKUXpPcm vESxH2EQGa6ksD8NV7pMNnbbgMXm4f+uincuNPzwkc9oPork5aDbuYOZwJjFG34esqK4 PlqPRNy74xeqEgyYxZTgSEG/5iCQVuivLUj+QyeZabqAvGg3nmicKjBqrZOPa9XTLlvT tbthT6RmeqtO56O/ok1lE9oyDZbOPXlwKpreaw70lb6YqhG+IJPivYvNfBNXbJGvnB7j ajsy0JA0HHnWrF+06xHtOIb3uJ7ss1CTWvbuLIN0IuZDYivCtAi2rOIOggGVOlaXSzpH pySQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718745462; x=1719350262; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sfWtmha6AvwTrs0xIGI0QAe+Hy7tn/djEUC/QZKg0sY=; b=oIJOvrM4Ahm7igp5kasAN6e43BdxDaYE8FlQL4oMmxWBBowDB4HqZvEK2sxYVgQN+n ZzHRaKueIPkWexCb04QhX0vFiEmZPUwW1pFN721thuYcJOrurW1DScgsOPszh66i7Lpz icKeuH2cAymKRC2V8Dyz22/qrC95B+GjKfKK+5FPEn7XpbpiZ4ItlUjGmf/RqEb9N5zD aZc+5AuY+tAAYim3l9xbF2c5lKumYRXV8elhfVieAr9bgdrA9iWzAwJpQZ3K7PwJLwXn Vs5tsN7fFvxFL3RBREV7b/oW21dfVSXa7m9qvFLyTqXg2PRd4/hsalXJk4VnIaWHm0mk uK1w== X-Gm-Message-State: AOJu0YwB6ylgMwbW7AO08GJOH5Dd31UsvbkGAE3/ukuG72IRwNgB9x83 +CJr+qV2Yerb8a7GX9QOf/PavxDcWI+seO6hCwjfAYrD7dfHUyGZQsDCHu4qhDVREVpKtyjA0C/ w60wy+NNEjCHWrWjBWlUoE9Aouk4= X-Google-Smtp-Source: AGHT+IFPUq3faOfHXdaI6/EAwkqA3AXR5nXIFDtVheUmZEZ/AT8ns5xp/2Ne1vFuijhNC6d7KfWhXGyWg5FcD3Zu/SA= X-Received: by 2002:a50:d619:0:b0:57d:73c:9299 with SMTP id 4fb4d7f45d1cf-57d07e752fbmr332628a12.23.1718745462045; Tue, 18 Jun 2024 14:17:42 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Jun 2024 14:17:41 -0700 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CAJ3okZ0DuvXjsrxaL9sefQhpssWR+a+pCUraca+r6FibnksWfA@HIDDEN> References: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN> <87lercwb0o.fsf@HIDDEN> <handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org> <87sexkj3ol.fsf@HIDDEN> <CADwFkmnXADA_mMA9g1Z=-8b=X0VicfcLBHCGL9bn4w9PFZ2X7w@HIDDEN> <CAJ3okZ0DuvXjsrxaL9sefQhpssWR+a+pCUraca+r6FibnksWfA@HIDDEN> MIME-Version: 1.0 Date: Tue, 18 Jun 2024 14:17:41 -0700 Message-ID: <CADwFkm=Q-ahpkVodnRi48eZb1THnWYcN15QaA=dyZJNZpQVEoQ@HIDDEN> Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogY2xvc2VkIChSZTogYnVnIzU3NDA3OiBbUEFUQ0hdIEhhbmRsZQ==?= =?UTF-8?B?IGVycm9yIG9mIOKAmXZjLXJlZ2lzdGVyZWTigJkp?= To: Simon Tournier <zimon.toutoune@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57407 Cc: Dmitry Gutov <dmitry@HIDDEN>, 57407 <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 (-) Simon Tournier <zimon.toutoune@HIDDEN> writes: > The previous comments appear to me very good ones and they are real > improvements. I do not promise to implement in timely manner but I > will do my best to dedicate some time before my summer holidays -- > always the good time for rushing and cleaning the endless TODO list. > ;-) Sounds good. Please let us know when you have a new patch.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 18 Jun 2024 20:42:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 18 16:42:43 2024 Received: from localhost ([127.0.0.1]:51549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sJff9-0000Fz-96 for submit <at> debbugs.gnu.org; Tue, 18 Jun 2024 16:42:43 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:41227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>) id 1sJff7-0000Fb-2O for 57407 <at> debbugs.gnu.org; Tue, 18 Jun 2024 16:42:41 -0400 Received: by mail-ot1-f48.google.com with SMTP id 46e09a7af769-6f9a24be44cso108719a34.1 for <57407 <at> debbugs.gnu.org>; Tue, 18 Jun 2024 13:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718743292; x=1719348092; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bfq7HzOizozzMARQrHxE3OdXsNnidvBZ+U43uV6fFb8=; b=lSkTRr824BtbMX/znlP5QMn/eJsTBsJf+aq2AZzJEZvzcsoQ/ll1ONDvg/sfr8goaw UQYHTBe/+KGhUq6S/ZMhBODEm2ur0fBFM8JT2UuzOi+ae83jmPdc+QiEEw4HPTjz/W1K n9wWs7xwDRNt8Eiy8xHXMx/FPWSC9xr2FLdq9p+fyCfwokVLtV/8FWasKfEVQTWoMi/D s198+EvqosnzdY3YxMaP7v39KkT5inwZkzsmOYiq46f4DbsV3C/sPPX7ldv0BZtLXjA5 yc1hoCZffuOLZL5JA8nIqus59BECBhNUVpsAPk4ZJ6o4hWk7/c1o4SEzzelFeFat/9oW NKXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718743292; x=1719348092; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bfq7HzOizozzMARQrHxE3OdXsNnidvBZ+U43uV6fFb8=; b=PpKKN+rq+4o2pIvGNohmV2KUzOuO33gsqkoGD2XyYJMC2f+lnKShf1TxYkiNapBO/d FMlY+Im9mLbNzSH5Uw72I8pLSLRL4rEIgHlRofGDT7MEdDChfTmE8mu57LVal/Grhg7Y rLcq/9BkSBmluTqy/vi54jwXXbRWXFtOGXg4F79jF9pohdKnBx/GOl/NA86M4x6ysdqB SGneml4IVwnc1jTa+rLi1GSZ+ViKdcOZJjED+tl5rofg3AaGCBB0Melcrv6QGeVbS5ny c3uz9+H3PQLuiP6YxUCAVlIlWzLcxS2QL11bwerWAfbhK+inrldhbKi3TO7ZTkHTWBHs nLgQ== X-Gm-Message-State: AOJu0YyoLORaTiOCqLOVNAsc0xMG7wZFQpNG77fIQ4YRn2V3eGsCHKKR oyhvHrkVfESDNzTrKZ5FJnYPoMxOe1B15GZsD5GECH+trDd1dy8+WhCIldgLI+6c5zEw8HiccpW 3OYAkjknmnN2lZgkoossVC8o7Reg= X-Google-Smtp-Source: AGHT+IFOy/GZwR2QWOhKjllnEuX9KxNFjjJv2yw+bPEt5y3578WQBoZGFxeqG6LeFgUH9g193CeYd0cXMnNE9xMEmvw= X-Received: by 2002:a05:6830:63c5:b0:6f9:7deb:f3b4 with SMTP id 46e09a7af769-700706a6c62mr975627a34.0.1718743292507; Tue, 18 Jun 2024 13:41:32 -0700 (PDT) MIME-Version: 1.0 References: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN> <87lercwb0o.fsf@HIDDEN> <handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org> <87sexkj3ol.fsf@HIDDEN> <CADwFkmnXADA_mMA9g1Z=-8b=X0VicfcLBHCGL9bn4w9PFZ2X7w@HIDDEN> In-Reply-To: <CADwFkmnXADA_mMA9g1Z=-8b=X0VicfcLBHCGL9bn4w9PFZ2X7w@HIDDEN> From: Simon Tournier <zimon.toutoune@HIDDEN> Date: Tue, 18 Jun 2024 22:41:19 +0200 Message-ID: <CAJ3okZ0DuvXjsrxaL9sefQhpssWR+a+pCUraca+r6FibnksWfA@HIDDEN> Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogY2xvc2VkIChSZTogYnVnIzU3NDA3OiBbUEFUQ0hdIEhhbmRsZQ==?= =?UTF-8?B?IGVycm9yIG9mIOKAmXZjLXJlZ2lzdGVyZWTigJkp?= To: Stefan Kangas <stefankangas@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57407 Cc: Dmitry Gutov <dmitry@HIDDEN>, 57407 <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 (-) Hi Stefan, Thank you for keeping an eye on the tracker. It's very valuable in order to maintain actionable fixes. On Tue, 18 Jun 2024 at 21:04, Stefan Kangas <stefankangas@HIDDEN> wrote: > Dmitry, what do you think of installing the proposed patch as is? The previous comments appear to me very good ones and they are real improvements. I do not promise to implement in timely manner but I will do my best to dedicate some time before my summer holidays -- always the good time for rushing and cleaning the endless TODO list. ;-) Cheers, simon
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Debbugs Internal Request <help-debbugs@HIDDEN>
to internal_control <at> debbugs.gnu.org.
Full text available.Received: (at 57407) by debbugs.gnu.org; 18 Jun 2024 19:05:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 18 15:05:35 2024 Received: from localhost ([127.0.0.1]:48810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sJe98-0002Kb-WA for submit <at> debbugs.gnu.org; Tue, 18 Jun 2024 15:05:35 -0400 Received: from mail-ej1-f51.google.com ([209.85.218.51]:51352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1sJe97-0002KB-4d for 57407 <at> debbugs.gnu.org; Tue, 18 Jun 2024 15:05:33 -0400 Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a63359aaaa6so899899366b.2 for <57407 <at> debbugs.gnu.org>; Tue, 18 Jun 2024 12:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718737464; x=1719342264; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=srgOoUQNmcF6reqyVzHjJpBj9+DkePHtsJ7dIWAim/4=; b=Je2SU7cSOWFffmpsPp4/GTIR9K3ntAQN9b/MU4CoRNRn2Zc/UPZ+V90WER4HlqYM7l KmGP/3G6hLbh9oPqRbg6lYI6jssk8vG+sBXhf9zATVo497+PiFtCtYF2J1Ryuo1wZ6hC vzTf7pOo3VilN1A0PpokuFxDth7M4MtBbl6lgCUGr1z/hIXrpX/rheU+qp8giPv3Elzg Q4C2EAhnMJvG26s82r1S+O7Y6TUdqAkyaAqsoYIbPCbupR52lK/JDBLmWA4gN6PUM0rW AFFEAg2gyysxpQL9VLgdjDJUwIMJdcfQiVeIN5UYZnF4ze1z2x7r8VWOAIj5k5LJ14yC pqcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718737464; x=1719342264; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=srgOoUQNmcF6reqyVzHjJpBj9+DkePHtsJ7dIWAim/4=; b=LBqCBB6JIXoLBr5JtYJl0bhVZ8tS6Xoc4HA3y2gOXkdyCIHz0BpCkKijnvLnWdr9Rw jD3H4e03zdRysynbmc2HFJ89mbLRoLekgIjd2JXA6zjZCQiHVqgMtYyIOl8IGKi4qa9E Hft0tuDwEcWsnQFfNIcw2tx6HCISXJOCAKjuQ+G3pFMeDA0jEf7dgs0S48spiLadoCcq R3wHw5H9yFdBM1Wnki2/fFyK3Y8F0IJiqxuCw91gw5fiQUKmnW8glLDO64Tmf9wfO+4V g1Ob4x3pKgvHFdaiQ1fiyvpIdK4pjftGcYho5sxxlUG1WMZv5zEKjZpjaZLhJh6xB4j0 1wjg== X-Gm-Message-State: AOJu0YwC5i3NQZ7VeZggNId5nO8XtQLuN6JtDWkfSLuuQB4Nx+HapCTr GGLRZeYgbISgpmkE/bBsC3VPNAesBpKX39MQr2msosGWovCYEkTQsJIW6n9SePI4oo/ZHOd6Qmg wXH8GUGsyViKfG5z7J+kSAjKSCn4= X-Google-Smtp-Source: AGHT+IE9ssSywZxK5+RwNdQveY1nQDGiUWmNpjXF1bdchGX2Zv8z9dgAusOsVPoSoheyo3xvEiRtje2TYFU2YHmipd8= X-Received: by 2002:a17:907:168b:b0:a6f:5698:ab5b with SMTP id a640c23a62f3a-a6fab60bab5mr21216866b.8.1718737464228; Tue, 18 Jun 2024 12:04:24 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Jun 2024 12:04:23 -0700 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87sexkj3ol.fsf@HIDDEN> References: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN> <87lercwb0o.fsf@HIDDEN> <handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org> <87sexkj3ol.fsf@HIDDEN> MIME-Version: 1.0 Date: Tue, 18 Jun 2024 12:04:23 -0700 Message-ID: <CADwFkmnXADA_mMA9g1Z=-8b=X0VicfcLBHCGL9bn4w9PFZ2X7w@HIDDEN> Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogY2xvc2VkIChSZTogYnVnIzU3NDA3OiBbUEFUQ0hdIEhhbmRsZQ==?= =?UTF-8?B?IGVycm9yIG9mIOKAmXZjLXJlZ2lzdGVyZWTigJkp?= To: Simon Tournier <zimon.toutoune@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57407 Cc: Dmitry Gutov <dmitry@HIDDEN>, 57407 <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 (-) reopen 57407 thanks Simon Tournier <zimon.toutoune@HIDDEN> writes: >>> That was one year ago. >>> >>> Simon, did you have a chance to look into the issues that Dmitry >>> mentioned below? >> >> More information was requested, but none was given within 9 months, so >> I'm closing this bug. If this is still an issue, please reply to this >> email (use "Reply to all" in your email client) and we can reopen the >> bug report. > > The issue is not gone, AFAICT. The cover letter provides a reproducer; > see below. OK, thanks, reopening the bug. > Well, I am not following very closely the development of Emacs master, > so I cannot tell with high confidence if a workaround introduced > elsewhere fixes the issue. However, from my quick look, the code that > triggers the spurious messages has not been changed. > > Sorry to not have the time to send a v2; I am running out of time. > However, closing this report: > > 1. Do not change that 991e145450ec8b02865597bc80fd797e39e81f07 is > clearly incorrect. It=E2=80=99s a regression > > 2. My patch, while imperfect, fixes such regression. Dmitry, what do you think of installing the proposed patch as is? Does it introduce any other regressions?
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 18 Jun 2024 14:04:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 18 10:04:36 2024
Received: from localhost ([127.0.0.1]:43812 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sJZRr-0004Ps-Hp
for submit <at> debbugs.gnu.org; Tue, 18 Jun 2024 10:04:35 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:41851)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <zimon.toutoune@HIDDEN>) id 1sJZRm-0004PN-37
for 57407 <at> debbugs.gnu.org; Tue, 18 Jun 2024 10:04:31 -0400
Received: by mail-wr1-f51.google.com with SMTP id
ffacd0b85a97d-35904026d72so508428f8f.3
for <57407 <at> debbugs.gnu.org>; Tue, 18 Jun 2024 07:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1718719401; x=1719324201; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=gqNvUyV/GsbsKo76uPmgytm0bX0Q+uym7oiMcjc0T9w=;
b=GEgHAFN3eqKX3t8W8vIfyayc1itO/JrrmTZ3j0y13qRmS41wHYoMC0CSv5bZnKXRkS
1uRZtvGGUlpne0f3hxXqtoAGXgS0bg8nzKr8fuzRZixdiw/AJ+AWe2RgzWmSwJ2BDoqx
/v/QfSH+Ypl1O0RV47SF1Htl6BorWBSJPviBoMbDFOU66tcijP6ZUv/glyrXq1Fji028
rQmB7x+nn672wwHtkFWDhUujipmATNQGU+TxL8JVJHLW4P2W5N/oPYc45hsRF9mzRsH4
GUU75k8jwqnDeQWpUMGMpMoMd7Lvag0MSKhMUW720kkQKgM+7tQ0yhR92Zi2qPc6QxU+
S1AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1718719401; x=1719324201;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=gqNvUyV/GsbsKo76uPmgytm0bX0Q+uym7oiMcjc0T9w=;
b=fUDiZ02ya/tzMXhCgHNyiHtM+76c53IRZmGTBdL++q1aSgWnDZZROqp+5542Y31ovz
7bytrBMZuDToh/VrPUrbhAhCa9k2zLqZAkZNpwiyRJuFSEXdmogk6rqoGsmIRHJQIbfR
ANyQok6iKEKps2FRuIzoEEPZb1WTINifIZrgNNyKJw/IEUrr+EAEnxsuj/Qf0uvy7sXN
ioTsR2sCKCXLlG+d76bOXM9JscL83D7Uh21YOGWaY6EQk14XazuYZIYgmfGaH6jync+b
rGaoXXhJhoQzufJGQs5GuBeTQrnfhNzCEe/uvzCGUdxwj99fcc6hL3siBmu51/3IiHf4
8dZQ==
X-Gm-Message-State: AOJu0YxTlfW+cjkT9VL0Xl3TU/Z1Ha2jg3z11i2C2Xjk2eeSyVBpHX0D
qeCw2Sr0KClBE/sm/XrLx7Gz0JA1uxwDNvWhjUSW/vX6kJ96zUWL8NoQmw==
X-Google-Smtp-Source: AGHT+IE6Go/WCo1N7F5yphDRJKuDWGMbLo9WxjvRSch8rQYQqR9lEY5T3z1QEoyHAvBQcYi13Y4Whg==
X-Received: by 2002:a5d:64e9:0:b0:35f:2929:8432 with SMTP id
ffacd0b85a97d-3607a720568mr10328011f8f.2.1718719401543;
Tue, 18 Jun 2024 07:03:21 -0700 (PDT)
Received: from lili ([131.254.253.81]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-360750f2295sm14233813f8f.82.2024.06.18.07.03.20
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 18 Jun 2024 07:03:21 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
To: stefankangas@HIDDEN
Subject: Re: bug#57407: closed (Re: bug#57407: [PATCH] Handle error of
=?utf-8?Q?=E2=80=99vc-registered=E2=80=99=29?=
In-Reply-To: <handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org>
(GNU bug Tracking System's message of "Sun, 09 Jun 2024 22:18:02
+0000")
References: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN>
<87lercwb0o.fsf@HIDDEN>
<handler.57407.D57407.17179714307188.notifdone <at> debbugs.gnu.org>
Date: Mon, 10 Jun 2024 16:03:06 +0200
Message-ID: <87sexkj3ol.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.1 (++)
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: Hi, On Sun, 09 Jun 2024 at 22:18, help-debbugs@HIDDEN (GNU
bug Tracking System) wrote: >> That was one year ago. >> >> Simon, did you
have a chance to look into the issues that Dmitry >> mentioned below? > >
More information was requested, but none was given within 9 months, so >
I'm cl [...]
Content analysis details: (2.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (zimon.toutoune[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received:
date -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.51 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.221.51 listed in list.dnswl.org]
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 57407
Cc: 57407 <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.1 (+)
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: Hi, On Sun, 09 Jun 2024 at 22:18, help-debbugs@HIDDEN (GNU
bug Tracking System) wrote: >> That was one year ago. >> >> Simon, did you
have a chance to look into the issues that Dmitry >> mentioned below? > >
More information was requested, but none was given within 9 months, so >
I'm cl [...]
Content analysis details: (1.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.51 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.51 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (zimon.toutoune[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received:
date
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Hi,
On Sun, 09 Jun 2024 at 22:18, help-debbugs@HIDDEN (GNU bug Tracking System=
) wrote:
>> That was one year ago.
>>
>> Simon, did you have a chance to look into the issues that Dmitry
>> mentioned below?
>
> More information was requested, but none was given within 9 months, so
> I'm closing this bug. If this is still an issue, please reply to this
> email (use "Reply to all" in your email client) and we can reopen the
> bug report.
The issue is not gone, AFAICT. The cover letter provides a reproducer;
see below.
> From: Simon Tournier <zimon.toutoune@HIDDEN>
> Subject: [PATCH] Handle error of =E2=80=99vc-registered=E2=80=99
> To: bug-gnu-emacs@HIDDEN
> Date: Thu, 25 Aug 2022 18:20:07 +0200
> Date: Thu, 25 Aug 2022 18:20:07 +0200 (1 year, 41 weeks, 2 days ago)
>
> Hi,
>
> Submission (Bug#18481) [0] merged on 2020-08-13 with commit
> 991e145450ec8b02865597bc80fd797e39e81f07 [1] aims to:
>
> =E2=80=9CNotify the user if we errors when querying for registered git fi=
les=E2=80=9C
>
> However, the replacement of =E2=80=99ignore-errors=E2=80=99 by =E2=80=99w=
ith-demoted-errors=E2=80=99
> introduces spurious messages. This patch proposes to handle the errors
> in a way that:
>
> 1. the user is still informed (avoid silent error)
> 2. improve the messages trying to be more accurate
> 3. do it for all the VC backends
>
> 0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18481
> 1:
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D991e145450ec8b02=
865597bc80fd797e39e81f07
>
>
>
> First, let compare the previous situation with the patched one. If the
> user runs =E2=80=99find-file=E2=80=99 in a Git repository without having =
installed the
> Git binary, then Emacs complains and the error is misleading.
> Reproducer:
>
> $ which git
> which: no git in =E2=80=A6
> $ mkdir -p /tmp/Git/.git
> $ emacs -q --batch --eval=3D"(find-file \"/tmp/Git/foo\")"
> Error: (file-missing "Searching for program" "No such file or directory" =
"git")
> Package vc-mtn is deprecated
>
>
> Not having a working Git installation is not an error for opening one
> file belonging to a folder containing a =E2=80=99.git=E2=80=99 subdirecto=
ry. For
> instance, if an user processes many files reporting many messages, then
> it seems hard to locate the real error, if any.
>
>
> Moreover, the messages are inconsistent depending on the VC backend;
> from nothing reported to a backtrace.
>
> $ mkdir -p /tmp/Bzr/.bzr
> $ emacs -q --batch --eval=3D"(find-file \"/tmp/Bzr/foo\")"
> Error: (file-missing "Searching for program" "No such file or directory" =
"bzr")
> Error: (file-missing "Searching for program" "No such file or directory" =
"bzr")
>
> Error: file-missing ("Searching for program" "No such file or directory" =
"bzr")
>
> [...]
>
> Searching for program: No such file or directory, bzr
Well, I am not following very closely the development of Emacs master,
so I cannot tell with high confidence if a workaround introduced
elsewhere fixes the issue. However, from my quick look, the code that
triggers the spurious messages has not been changed.
Sorry to not have the time to send a v2; I am running out of time.
However, closing this report:
1. Do not change that 991e145450ec8b02865597bc80fd797e39e81f07 is
clearly incorrect. It=E2=80=99s a regression
2. My patch, while imperfect, fixes such regression.
Cheers,
simon
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407-done) by debbugs.gnu.org; 9 Jun 2024 22:17:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 09 18:17:10 2024 Received: from localhost ([127.0.0.1]:35782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sGQqc-0001rr-1K for submit <at> debbugs.gnu.org; Sun, 09 Jun 2024 18:17:10 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:47244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1sGQqa-0001rT-Tf for 57407-done <at> debbugs.gnu.org; Sun, 09 Jun 2024 18:17:09 -0400 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4217990f8baso13299805e9.2 for <57407-done <at> debbugs.gnu.org>; Sun, 09 Jun 2024 15:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717971346; x=1718576146; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=76A7v/RaSCNwGmH56LXQuOYzNhUb7lDZgKfs9zvAbKc=; b=L8pTHb5XDBTwyngnHXYBMc6q94VIv1xaqW0i+exlmpcpVCd6RCYj0AtA2IQXvpACyD GRxgJ8CJb7GsByQiLLlIm3pHHNG0B22tdU3WcjTAf6T03nIEudRoXMhVhwRgMGy+cyDO DYPamzlZwa8FlZkDfY08ul0FCdWG9ZYUdv9VvdwPwE3CiyaZDE3aa1CZ2hgoHebtHZoi qicJ1NZCq1SAqpAFYZsX6VdAmQ/7PRgLMMeU/ji2f4rJW5cE9AT92VLRsfo/g1BAqS2N 5uB4bODjjj2QdaAK+RIwBu/UdQ0S2e4mQzmsNSpPg39IJ25dFM+oeW6bCrB7tp2H6vPV ynww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717971346; x=1718576146; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=76A7v/RaSCNwGmH56LXQuOYzNhUb7lDZgKfs9zvAbKc=; b=mjmbH+7NcHKAuBcUEn/1I5XA9MTw2hzpHaEF5mCua4YN5TLGU71z8eozS68HSanHOs pM55iSDhI46B/UYt6CCJAdSzJ4jt7fsEkwhm3Y7rM2lvQWieUYh7jgaE1zcA1xQY+nMG WInZtNJgfHVUeTFRXUfLoHXkvVKZazmv6Ubq+xxzxBfXUg/VLUn6/pPof2nAdUaaVFIE NiYtoHuQeVrOD/49yDSF4IeYfyQ9Gq2f1YVB8CQHJvAd7+EoWrdKVsfAm58P6sqJu9XR sh7sKLhPg0QXoa9TH7UkRT1Ir39KNKh7le8Di7xij9Z9AYTIv3PhC6sTIi61LGXg2L/K R9Sg== X-Gm-Message-State: AOJu0YzHlfSueb30eVaanA6gH9Ld3P3inl1AZLlFdkr1fQluagTj0Xem B6GCAIWZEM9TOkHbJk8MjK+DXmYh6Zj+5c1GhGbb9C+gf5Egfb4IzL+Zu2p0KGK3/ssj0xai8+P tB+JWrlBnoTTl1mL9n07zxi/eZ7KOFo/9GAg= X-Google-Smtp-Source: AGHT+IFFAMYHOl93efnmkLve7FqeG4U8sRoBIT7Jnt4lIfz9kWhaa7VOO80v+vqFYUhIkXu3uW4dMUU5O+5DPChO6xQ= X-Received: by 2002:a50:cdc1:0:b0:57c:7641:72e2 with SMTP id 4fb4d7f45d1cf-57c76417319mr1765459a12.30.1717966897128; Sun, 09 Jun 2024 14:01:37 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 9 Jun 2024 17:01:36 -0400 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CADwFkmnNROfD0yzFtkV5nTqawogyH4zJPOQXPQ+SSLJEKsj-ag@HIDDEN> (Stefan Kangas's message of "Wed, 6 Sep 2023 15:48:45 -0700") References: <87lercwb0o.fsf@HIDDEN> <f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN> <87czc0eqfn.fsf@HIDDEN> <1529983c-f487-0e27-338e-9c537d2c7169@HIDDEN> <CADwFkmnNROfD0yzFtkV5nTqawogyH4zJPOQXPQ+SSLJEKsj-ag@HIDDEN> MIME-Version: 1.0 Date: Sun, 9 Jun 2024 17:01:36 -0400 Message-ID: <CADwFkmn6b3XhRBXH=-+ur8KrKP3XpDpOf76B7-ZgRNa1vHiT-A@HIDDEN> Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogW1BBVENIXSBIYW5kbGUgZXJyb3Igb2Yg4oCZdmMtcmVnaXN0ZQ==?= =?UTF-8?B?cmVk4oCZ?= To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57407-done Cc: 57407-done <at> debbugs.gnu.org, Simon Tournier <zimon.toutoune@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 Kangas <stefankangas@HIDDEN> writes: > That was one year ago. > > Simon, did you have a chance to look into the issues that Dmitry > mentioned below? More information was requested, but none was given within 9 months, so I'm closing this bug. If this is still an issue, please reply to this email (use "Reply to all" in your email client) and we can reopen the bug report.
Simon Tournier <zimon.toutoune@HIDDEN>:Stefan Kangas <stefankangas@HIDDEN>:
Received: (at 57407) by debbugs.gnu.org; 6 Sep 2023 22:49:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 06 18:49:10 2023
Received: from localhost ([127.0.0.1]:38093 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qe1KS-0001qZ-Ly
for submit <at> debbugs.gnu.org; Wed, 06 Sep 2023 18:49:10 -0400
Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:52522)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stefankangas@HIDDEN>) id 1qe1KP-0001qG-Sa
for 57407 <at> debbugs.gnu.org; Wed, 06 Sep 2023 18:48:54 -0400
Received: by mail-lf1-x131.google.com with SMTP id
2adb3069b0e04-501bd6f7d11so483886e87.1
for <57407 <at> debbugs.gnu.org>; Wed, 06 Sep 2023 15:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1694040526; x=1694645326; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=VJozwHPzxAB1y/rfZ48hsPEeRKQ3zAMlYKLMslvaMI0=;
b=MFtamAozJNJWq9u/d3Wk57YICIu82twCcRU+j5v19Qe5Xue3ESg2ztXT09LWUgh1d2
A0WjE3O3Vk6Pn1GOQxIikCguX+9BBDiR750M9basdwwrf86GQ+TqDHWPAFco4UsDV+OB
U8z6uhqLeRmQ+2VhYM7eO3+/GpKLPOOjI6DEAkH443UG2zbjTzs8TKeaIRORWuV5RnZH
zGjZuL0zAx+iPE1wEzdOGRLw2ftFJIYnNqivNo7MMhlaI5jXoLEa87NMVd/+cbVPQzuO
pz6f5qTLInlkOdIf1wQMJn7ILRz1gAEf0c4d/Q5iampi8HPS05o0YTkd/s+6URlaoGbv
HwIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1694040526; x=1694645326;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:x-gm-message-state:from:to
:cc:subject:date:message-id:reply-to;
bh=VJozwHPzxAB1y/rfZ48hsPEeRKQ3zAMlYKLMslvaMI0=;
b=P5KvwJ6ztVkoMz/JEW7LBX55XI4CqhIeMdyji1NeHDohKG83Zf4xnir4P2kbjDJ/4l
WJmPCsPsdg4JgShB50TEwWniLdaqs737T3+JMFWZ4W4VTS3MR+aUXjueBybK+lbpEjSn
rwgI5iMLMP203LQkBrdczus8SoKEi4SJCajjlesBYjfd6d+f8LNbiASbzVpULxuNGkSq
i8SR1ATDLQyZ3rRxv17MXV+Y3yxJHS23p4Cjw3qHdcMEF1OHRXUrDCoYPoGD7+owTGcl
qknDzm6fcxwWlnjlYl/i61srwAZCbB8Of7z+wTX9ekfH+BonQBX+RUL0ojtwuZk0k0vK
mRFQ==
X-Gm-Message-State: AOJu0YzSqOvlpFnMzNmGlA++9M/u7TSxwYhWWaue4qLVqE3c9e6Rhy42
wmivYqPaIaO25acfMOe9wszE+G3s4t11LWOJQxs=
X-Google-Smtp-Source: AGHT+IF36Savezya2yIJVcVb169YHBeVFrfj4GTUJ0ktWHe48GFW3FxS1wzMwx82DpihCDMbyHCjVFWK8g7zUAWsRJo=
X-Received: by 2002:ac2:5326:0:b0:500:95f7:c416 with SMTP id
f6-20020ac25326000000b0050095f7c416mr3063792lfh.7.1694040526193; Wed, 06 Sep
2023 15:48:46 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Wed, 6 Sep 2023 15:48:45 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <1529983c-f487-0e27-338e-9c537d2c7169@HIDDEN> (Dmitry Gutov's
message of "Fri, 30 Sep 2022 03:55:50 +0300")
References: <87lercwb0o.fsf@HIDDEN>
<f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN>
<87czc0eqfn.fsf@HIDDEN> <1529983c-f487-0e27-338e-9c537d2c7169@HIDDEN>
MIME-Version: 1.0
Date: Wed, 6 Sep 2023 15:48:45 -0700
Message-ID: <CADwFkmnNROfD0yzFtkV5nTqawogyH4zJPOQXPQ+SSLJEKsj-ag@HIDDEN>
Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogW1BBVENIXSBIYW5kbGUgZXJyb3Igb2Yg4oCZdmMtcmVnaXN0ZQ==?=
=?UTF-8?B?cmVk4oCZ?=
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 57407
Cc: 57407 <at> debbugs.gnu.org, Simon Tournier <zimon.toutoune@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 (-)
That was one year ago.
Simon, did you have a chance to look into the issues that Dmitry
mentioned below?
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 12.09.2022 15:18, Simon Tournier wrote:
>> Hi,
>> Thanks for your comments.
>> On lun., 12 sept. 2022 at 04:08, Dmitry Gutov <dgutov@HIDDEN> wrote:
>>
>>> Do I take this right that the main purpose of the patch is to have the =
"Error:
>>> ..." messages replaced with "Warning: ..."?
>> Somehow yes. More explicitly, replace =E2=80=9CError: <useless message>=
=E2=80=9D with
>> =E2=80=9CWarning: <more helpful>=E2=80=9D.
>
> Sounds good.
>
>>> But you also add a bunch of re-signaling code like
>>>
>>> + (let ((state (condition-case err
>>> + (vc-bzr-state-heuristic file)
>>> + (error (signal (car err) (cdr err))))))
>>>
>>> What is the idea behind this? Why not just keep the call?
>> What do you mean? You need to catch the error and propagates it.
>
> Why not just let it bubble up? Why catch it at all here?
>
> There is one condition-case that actually does something (in vc-do-comman=
d), but
> adding a condition-case with exactly one handler which simply re-throws d=
oesn't
> seem to change anything (except swallowing a part of the backtrace).
>
>> If the heuristic fails in vc-bzr-state-heuristic, then =E2=80=99vc-bzr-s=
tate=E2=80=99 is
>> called, which itself then calls =E2=80=99vc-bzr-status=E2=80=99. This s=
tatus function
>> can signal an error and it requires to be raised again.
>>
>>> And in vc-svn-registered, for example. You re-signal whatever error is =
caught,
>>> without any alternative. Do we need the condition-case there at all, th=
en?
>> Yes, you need to re-throw the error to propagate it. See
>> =E2=80=99(elisp)Handling Errors=E2=80=99:
>> Sometimes it is necessary to re-throw a signal caught by
>> =E2=80=98condition-case=E2=80=99, for some outer-level handler to =
catch. Here=E2=80=99s
>> how to do that:
>> (signal (car err) (cdr err))
>> where =E2=80=98err=E2=80=99 is the error description variable, the=
first argument
>> to =E2=80=98condition-case=E2=80=99 whose error condition you want=
to re-throw.
>> Or I am missing a point. :-)
>
> You indeed might end up re-signaling errors this way, but that's only use=
ful if
> the condition-case form has some other purpose to begin with (aside from
> re-throwing). Like catching different kinds of errors, logging some one w=
ay and
> re-throwing others. Like you do in vc-do-command.
>
> If you simply want to stop swallowing the errors in some form, you can ju=
st
> remove the condition-case form.
>
>>> Furthermore, we'll have to examine the resulting effect on the behavior=
of
>>> various backend methods. Apparently, up until now vc-svn-registered nev=
er
>>> signaled an error (swallowed all of them). And now whatever callers it =
has,
>>> will need to handle possible errors.
>> I think it is what this patch is doing: handle possible errors by the
>> =E2=80=99vc-<backend>-registered=E2=80=99 callers.
>
> Have you looked at this comment in vc-svn-registered?
>
> ;; Some problem happened. E.g. We can't find an `svn'
> ;; executable. We used to only catch `file-error' but when
> ;; the process is run on a remote host via Tramp, the error
> ;; is only reported via the exit status which is turned into
> ;; an `error' by vc-do-command.
>
> I wonder if that's still true.
>
>>> It's probably fine, though. vc-backend is a more popular function, and =
it
>>> seems not much is changing for it, since, for some reason, vc-refresh-s=
tate
>>> wrapped its call in with-demoted-errors anyway.
>> For what my opinion is worth, the commit
>> 991e145450ec8b02865597bc80fd797e39e81f07 =E2=80=93 which replaces
>> =E2=80=99ignore-errors=E2=80=99 with =E2=80=99with-demoted-errors=E2=80=
=99 only for the Git backend =E2=80=93 is
>> a valuable idea but incorrectly implemented. This patch is an attempt
>> to improve the situation.
>>
>>> But I think we have other callers of it in-tree, and not all of them gu=
ard
>>> with with-demoted-errors or condition-case. What do you think we should=
do
>>> with them?
>> Could you be more specific about these =E2=80=9Cother callers=E2=80=9D? =
From my
>> understanding, =E2=80=99vc-<backend>-registered=E2=80=99 is called by =
=E2=80=99vc-registered=E2=80=99
>> and this patch handles this case; even =E2=80=99vc-registered=E2=80=99 i=
s not modified
>> by this patch and the handler happens in =E2=80=99vc-refresh-state=E2=80=
=99.
>
> vc-registered and vc-dir-recompute-file-state call it.
>
> And vc-deduce-fileset-1 calls vc-registered. I suppose some or all of the=
se
> should catch errors now?
>
>> Moreover,
>> --8<---------------cut here---------------start------------->8---
>> $ for backend in svn git hg ;do ag --elisp vc-${backend}-registered ;don=
e
>> lisp/ldefs-boot.el
>> 33455: (defun vc-svn-registered (f)
>> 33462: (vc-svn-registered f))))
>> lisp/vc/vc-svn.el
>> 110:;; vc-svn-registered, but we want the value to be compiled at startu=
p, not
>> 133:;;;###autoload (defun vc-svn-registered (f)
>> 140:;;;###autoload (vc-svn-registered f))))
>> 142:(defun vc-svn-registered (file)
>> 242: (vc-svn-registered file)
>> lisp/ldefs-boot.el
>> 33399: (defun vc-git-registered (file)
>> 33404: (vc-git-registered file))))
>> lisp/vc/vc-git.el
>> 244:;;;###autoload (defun vc-git-registered (file)
>> 249:;;;###autoload (vc-git-registered file))))
>> 251:(defun vc-git-registered (file)
>> lisp/ldefs-boot.el
>> 33410: (defun vc-hg-registered (file)
>> 33415: (vc-hg-registered file))))
>> lisp/vc/vc-hg.el
>> 85:;; vc-hg-registered and vc-hg-state
>> 198:;;;###autoload (defun vc-hg-registered (file)
>> 203:;;;###autoload (vc-hg-registered file))))
>> 206:(defun vc-hg-registered (file)
>> --8<---------------cut here---------------end--------------->8---
>> means that another caller is =E2=80=99vc-svn-working-revision=E2=80=99 u=
sed by,
>> --8<---------------cut here---------------start------------->8---
>> (defun vc-working-revision (file &optional backend)
>> "Return the repository version from which FILE was checked out.
>> If FILE is not registered, this function always returns nil."
>> (or (vc-file-getprop file 'vc-working-revision)
>> (progn
>> (setq backend (or backend (vc-backend file)))
>> (when backend
>> (vc-file-setprop file 'vc-working-revision
>> (vc-call-backend
>> backend 'working-revision file))))))
>> --8<---------------cut here---------------end--------------->8---
>> Therefore, =E2=80=99vc-svn-working-revision=E2=80=99 should also be guar=
ded with
>> =E2=80=99condition-case=E2=80=99 and display an appropriate message, ind=
eed.
>>
>>>> It is probably an abuse of =E2=80=99pcase=E2=80=99. Is =E2=80=99cond=
=E2=80=99 better here? Last,
>>>> I have not found in the documentation how to differentiate what it is
>>>> raised depending on the error type, hence the =E2=80=99pcase=E2=80=99.
>>>
>>> I think you just need to write the specific error type instead of 'erro=
r' in
>>> the handler clause.
>> Maybe I am missing a point about error handling and how they propagate.
>> If I consider this change removing =E2=80=99pcase=E2=80=99 and write the=
specific error
>> as you are suggesting,
>> --8<---------------cut here---------------start------------->8---
>> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
>> index 778d1139fc..39ad27f2fd 100644
>> --- a/lisp/vc/vc-dispatcher.el
>> +++ b/lisp/vc/vc-dispatcher.el
>> @@ -361,15 +361,13 @@ vc-do-command
>> (let ((buffer-undo-list t))
>> (condition-case err
>> (setq status (apply #'process-file command nil t nil squeez=
ed))
>> - (error
>> - (pcase (car err)
>> - ('file-missing
>> - (if (string=3D (cadr err) "Searching for program")
>> - ;; The most probable is the lack of the backend=
binary.
>> - (signal 'vc-not-supported (cdr err))
>> - (signal (car err) (cdr err))))
>> - (_
>> - (signal (car err) (cdr err)))))))
>> + ((file-missing
>> + (if (string=3D (cadr err) "Searching for program")
>> + ;; The most probable is the lack of the backend b=
inary.
>> + (signal 'vc-not-supported (cdr err))
>> + (signal (car err) (cdr err))))
>> + (_
>> + (signal (car err) (cdr err))))))
>> (when (and (not (eq t okstatus))
>> (or (not (integerp status))
>> (and okstatus (< okstatus status))))
>> --8<---------------cut here---------------end--------------->8---
>> then instead of,
>> --8<---------------cut here---------------start------------->8---
>> Warning: (vc-not-supported "Searching for program" "No such file or dire=
ctory" "git")
>> --8<---------------cut here---------------end--------------->8---
>> the report is,
>> --8<---------------cut here---------------start------------->8---
>> VC refresh error: (void-function _)
>> --8<---------------cut here---------------end--------------->8---
>
> _ is syntax specific to pcase. condition-case uses 't' for the fallback h=
andler.
>
>> Well, I do not know how to avoid the =E2=80=99pcase=E2=80=99 here to cor=
rectly propagate
>> the errors.
>> About the other =E2=80=99pcase=E2=80=99, this code,
>> --8<---------------cut here---------------start------------->8---
>> ((setq backend (condition-case err
>> (vc-backend buffer-file-name)
>> ((vc-not-supported
>> (message "Warning: %S" err))
>> (_
>> (message "VC refresh error: %S" err)))))
>> --8<---------------cut here---------------end--------------->8---
>> does not raise the correct message.
>
> Does this work for you?
>
> ((setq backend (condition-case err
> (vc-backend buffer-file-name)
> (vc-not-supported
> (message "Warning: %S" err))
> (t
> (message "VC refresh error: %S" err))))
>
> And you can update the previous (more complex) example similarly, without=
pcase.
>
>> Somehow, I probably miss how to correctly propagate errors but the patch
>> is, IMHO, the simplest way.
>>
>>> Regarding the rest of the patch, could you explain the change in
>>> vc-bzr-state-heuristic? Looking at the code, I figure the idea was to
>>> future-proof the parser against some future change in file format, to f=
all
>>> back to (slower) calling the 'bzr' program. Are we somehow certain now =
this is
>>> not needed?
>> Nothing has really changed. The current pattern is:
>> --8<---------------cut here---------------start------------->8---
>> (condition-case err
>> (with-temp-buffer
>> ...
>> (if (not (looking-at "#bazaar dirstate flat format 3"))
>> (vc-bzr-state file) ; Some other unknown format?
>> (let* ...)))
>> ;; The dirstate file can't be read, or some other problem.
>> (error
>> (message "Falling back on \"slow\" status detection (%S)" err)
>> (vc-bzr-state file)))
>> --8<---------------cut here---------------end--------------->8---
>> where it means =E2=80=99vc-bzr-state=E2=80=99 is at two places =E2=80=93=
which is redundant.
>> Instead, the pattern,
>> --8<---------------cut here---------------start------------->8---
>> (condition-case err
>> (with-temp-buffer
>> ...
>> (if (not (looking-at "#bazaar dirstate flat format 3"))
>> (signal 'error "VC: Bzr dirstate is not flat format 3")
>> (let* ...)))
>> ;; The dirstate file can't be read, or some other problem.
>> (error
>> (message "Falling back on \"slow\" status detection (%S)" err)
>> (vc-bzr-state file)))
>> --8<---------------cut here---------------end--------------->8---
>> is better because it appears only at one location. Now, knowing if this
>> test about the BZR format is relevant or not is another story. :-)
>
> Makes sense now, thanks.
>
>> The patch is just tweaking how the errors are handled, not the logic
>> behind. In another patch, this =E2=80=99vc-bzr-state-heuristic=E2=80=99=
could be split;
>> as it is done with HG: vc-hg-state calling vc-hg-state-fast falling back
>> to vc-hg-state-slow =E2=80=93 instead of having the fast (heuristic) inc=
luded.
>
> Up to you.
>
>> Let me know how to proceed for helping in the review process.
>
> Let's address the raised points first. Thank you.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 30 Sep 2022 00:56:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 29 20:56:00 2022
Received: from localhost ([127.0.0.1]:39954 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oe4Js-0006GJ-2C
for submit <at> debbugs.gnu.org; Thu, 29 Sep 2022 20:56:00 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:36607)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1oe4Jq-0006G2-1Z
for 57407 <at> debbugs.gnu.org; Thu, 29 Sep 2022 20:55:58 -0400
Received: by mail-wr1-f54.google.com with SMTP id v28so4558108wrd.3
for <57407 <at> debbugs.gnu.org>; Thu, 29 Sep 2022 17:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding:in-reply-to:from:references:cc:to
:content-language:subject:user-agent:mime-version:date:message-id
:sender:from:to:cc:subject:date;
bh=buaFp05eHUoF0sfxjVt+MgmidPRV/p8AhZreQuPAGI0=;
b=Mzdk396GASL6L3PlsVQ69+lLieSwMMx2h3UCORqf7+nvMaKIRuxPuDUY9sM0dy5mgZ
K+49H+cYLfrq2wzs1TV5O401d3kpXX/lpaVU2w5BbccZoFxiXX8cE4euIHGhBBT0u+cz
GrSls5TstvPG5jQA3SeFjrOHZCfuZvZjWlF6UqLH+0X02H92vdQvzPEc+fep2/Hdf/3i
eodPOLn5kzeuJunMLdvO4tMrMFXAcfxbnmvKlR/Sqq2Yd4paR1jVAyeb119zG8ta6w0v
oYoC/2Fe4uNML2HYU76eYbr5LoutdxhCzQykEVwugsXRzD7qXzVoMxkealmYKCaQQtq0
oZaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:in-reply-to:from:references:cc:to
:content-language:subject:user-agent:mime-version:date:message-id
:sender:x-gm-message-state:from:to:cc:subject:date;
bh=buaFp05eHUoF0sfxjVt+MgmidPRV/p8AhZreQuPAGI0=;
b=hYWj68KhU1I/+r0pFfCyZ7/esQlG1bcEe+RgQI8Qi0JZwbeFrlqrwn2ItFhH05Nv6F
TAs3R+AdEhMJOTI06YFtw/owSRUEryGVCVh2uh3Yl5KZrky5aRa2nkmrljvE51QFcLUx
LzG4naTTqjEgK5e6ZdQeTRI31TyUG8O0LVgNlNyNljyq2OZm4az9NmygCqYBWt34A4XK
3qX7TwpseUOu/7my63ey8mY4IsYskwhHghS6Ze4CaClYubu6kuROE1HA2kjC1WmR1rQu
aI2KYIYdSUVklUTLHD+wGzDS9f8EBoEpCXE9oBvDZI6EWkeu/JnLBajWTvTxUwhoBfBk
ia/A==
X-Gm-Message-State: ACrzQf3Nc69ReM+456LyAz9JgTGFe71vW04SIVfhbFRsH+63lsWj89ww
32Vyle4ta+/qpJqnz2cEll8=
X-Google-Smtp-Source: AMsMyM7Dt2JA6BzY0sTebcxAwxPE+UjwJMmFhPFxjXHxmkBhAab8e14y53G1nrRjwN8uR5JkFdgxhg==
X-Received: by 2002:adf:fc0a:0:b0:22c:daaf:b179 with SMTP id
i10-20020adffc0a000000b0022cdaafb179mr3085156wrr.569.1664499352064;
Thu, 29 Sep 2022 17:55:52 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
by smtp.googlemail.com with ESMTPSA id
n186-20020a1ca4c3000000b003a8434530bbsm5472770wme.13.2022.09.29.17.55.51
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 29 Sep 2022 17:55:51 -0700 (PDT)
Message-ID: <1529983c-f487-0e27-338e-9c537d2c7169@HIDDEN>
Date: Fri, 30 Sep 2022 03:55:50 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogW1BBVENIXSBIYW5kbGUgZXJyb3Igb2Yg4oCZ?=
=?UTF-8?Q?vc-registered=e2=80=99?=
Content-Language: en-US
To: Simon Tournier <zimon.toutoune@HIDDEN>
References: <87lercwb0o.fsf@HIDDEN>
<f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN> <87czc0eqfn.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87czc0eqfn.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 57407
Cc: 57407 <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: -2.3 (--)
On 12.09.2022 15:18, Simon Tournier wrote:
> Hi,
>
> Thanks for your comments.
>
>
> On lun., 12 sept. 2022 at 04:08, Dmitry Gutov <dgutov@HIDDEN> wrote:
>
>> Do I take this right that the main purpose of the patch is to have the "Error:
>> ..." messages replaced with "Warning: ..."?
>
> Somehow yes. More explicitly, replace “Error: <useless message>” with
> “Warning: <more helpful>”.
Sounds good.
>> But you also add a bunch of re-signaling code like
>>
>> + (let ((state (condition-case err
>> + (vc-bzr-state-heuristic file)
>> + (error (signal (car err) (cdr err))))))
>>
>> What is the idea behind this? Why not just keep the call?
>
> What do you mean? You need to catch the error and propagates it.
Why not just let it bubble up? Why catch it at all here?
There is one condition-case that actually does something (in
vc-do-command), but adding a condition-case with exactly one handler
which simply re-throws doesn't seem to change anything (except
swallowing a part of the backtrace).
> If the heuristic fails in vc-bzr-state-heuristic, then ’vc-bzr-state’ is
> called, which itself then calls ’vc-bzr-status’. This status function
> can signal an error and it requires to be raised again.
>
>
>> And in vc-svn-registered, for example. You re-signal whatever error is caught,
>> without any alternative. Do we need the condition-case there at all, then?
>
> Yes, you need to re-throw the error to propagate it. See
> ’(elisp)Handling Errors’:
>
> Sometimes it is necessary to re-throw a signal caught by
> ‘condition-case’, for some outer-level handler to catch. Here’s
> how to do that:
>
> (signal (car err) (cdr err))
>
> where ‘err’ is the error description variable, the first argument
> to ‘condition-case’ whose error condition you want to re-throw.
>
> Or I am missing a point. :-)
You indeed might end up re-signaling errors this way, but that's only
useful if the condition-case form has some other purpose to begin with
(aside from re-throwing). Like catching different kinds of errors,
logging some one way and re-throwing others. Like you do in vc-do-command.
If you simply want to stop swallowing the errors in some form, you can
just remove the condition-case form.
>> Furthermore, we'll have to examine the resulting effect on the behavior of
>> various backend methods. Apparently, up until now vc-svn-registered never
>> signaled an error (swallowed all of them). And now whatever callers it has,
>> will need to handle possible errors.
>
> I think it is what this patch is doing: handle possible errors by the
> ’vc-<backend>-registered’ callers.
Have you looked at this comment in vc-svn-registered?
;; Some problem happened. E.g. We can't find an `svn'
;; executable. We used to only catch `file-error' but when
;; the process is run on a remote host via Tramp, the error
;; is only reported via the exit status which is turned into
;; an `error' by vc-do-command.
I wonder if that's still true.
>> It's probably fine, though. vc-backend is a more popular function, and it
>> seems not much is changing for it, since, for some reason, vc-refresh-state
>> wrapped its call in with-demoted-errors anyway.
>
> For what my opinion is worth, the commit
> 991e145450ec8b02865597bc80fd797e39e81f07 – which replaces
> ’ignore-errors’ with ’with-demoted-errors’ only for the Git backend – is
> a valuable idea but incorrectly implemented. This patch is an attempt
> to improve the situation.
>
>
>> But I think we have other callers of it in-tree, and not all of them guard
>> with with-demoted-errors or condition-case. What do you think we should do
>> with them?
>
> Could you be more specific about these “other callers”? From my
> understanding, ’vc-<backend>-registered’ is called by ’vc-registered’
> and this patch handles this case; even ’vc-registered’ is not modified
> by this patch and the handler happens in ’vc-refresh-state’.
vc-registered and vc-dir-recompute-file-state call it.
And vc-deduce-fileset-1 calls vc-registered. I suppose some or all of
these should catch errors now?
> Moreover,
>
> --8<---------------cut here---------------start------------->8---
> $ for backend in svn git hg ;do ag --elisp vc-${backend}-registered ;done
> lisp/ldefs-boot.el
> 33455: (defun vc-svn-registered (f)
> 33462: (vc-svn-registered f))))
>
> lisp/vc/vc-svn.el
> 110:;; vc-svn-registered, but we want the value to be compiled at startup, not
> 133:;;;###autoload (defun vc-svn-registered (f)
> 140:;;;###autoload (vc-svn-registered f))))
> 142:(defun vc-svn-registered (file)
> 242: (vc-svn-registered file)
> lisp/ldefs-boot.el
> 33399: (defun vc-git-registered (file)
> 33404: (vc-git-registered file))))
>
> lisp/vc/vc-git.el
> 244:;;;###autoload (defun vc-git-registered (file)
> 249:;;;###autoload (vc-git-registered file))))
> 251:(defun vc-git-registered (file)
> lisp/ldefs-boot.el
> 33410: (defun vc-hg-registered (file)
> 33415: (vc-hg-registered file))))
>
> lisp/vc/vc-hg.el
> 85:;; vc-hg-registered and vc-hg-state
> 198:;;;###autoload (defun vc-hg-registered (file)
> 203:;;;###autoload (vc-hg-registered file))))
> 206:(defun vc-hg-registered (file)
> --8<---------------cut here---------------end--------------->8---
>
> means that another caller is ’vc-svn-working-revision’ used by,
>
> --8<---------------cut here---------------start------------->8---
> (defun vc-working-revision (file &optional backend)
> "Return the repository version from which FILE was checked out.
> If FILE is not registered, this function always returns nil."
> (or (vc-file-getprop file 'vc-working-revision)
> (progn
> (setq backend (or backend (vc-backend file)))
> (when backend
> (vc-file-setprop file 'vc-working-revision
> (vc-call-backend
> backend 'working-revision file))))))
> --8<---------------cut here---------------end--------------->8---
>
> Therefore, ’vc-svn-working-revision’ should also be guarded with
> ’condition-case’ and display an appropriate message, indeed.
>
>
>>> It is probably an abuse of ’pcase’. Is ’cond’ better here? Last,
>>> I have not found in the documentation how to differentiate what it is
>>> raised depending on the error type, hence the ’pcase’.
>>
>> I think you just need to write the specific error type instead of 'error' in
>> the handler clause.
>
> Maybe I am missing a point about error handling and how they propagate.
> If I consider this change removing ’pcase’ and write the specific error
> as you are suggesting,
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
> index 778d1139fc..39ad27f2fd 100644
> --- a/lisp/vc/vc-dispatcher.el
> +++ b/lisp/vc/vc-dispatcher.el
> @@ -361,15 +361,13 @@ vc-do-command
> (let ((buffer-undo-list t))
> (condition-case err
> (setq status (apply #'process-file command nil t nil squeezed))
> - (error
> - (pcase (car err)
> - ('file-missing
> - (if (string= (cadr err) "Searching for program")
> - ;; The most probable is the lack of the backend binary.
> - (signal 'vc-not-supported (cdr err))
> - (signal (car err) (cdr err))))
> - (_
> - (signal (car err) (cdr err)))))))
> + ((file-missing
> + (if (string= (cadr err) "Searching for program")
> + ;; The most probable is the lack of the backend binary.
> + (signal 'vc-not-supported (cdr err))
> + (signal (car err) (cdr err))))
> + (_
> + (signal (car err) (cdr err))))))
> (when (and (not (eq t okstatus))
> (or (not (integerp status))
> (and okstatus (< okstatus status))))
> --8<---------------cut here---------------end--------------->8---
>
> then instead of,
>
> --8<---------------cut here---------------start------------->8---
> Warning: (vc-not-supported "Searching for program" "No such file or directory" "git")
> --8<---------------cut here---------------end--------------->8---
>
> the report is,
>
> --8<---------------cut here---------------start------------->8---
> VC refresh error: (void-function _)
> --8<---------------cut here---------------end--------------->8---
_ is syntax specific to pcase. condition-case uses 't' for the fallback
handler.
> Well, I do not know how to avoid the ’pcase’ here to correctly propagate
> the errors.
>
>
> About the other ’pcase’, this code,
>
> --8<---------------cut here---------------start------------->8---
> ((setq backend (condition-case err
> (vc-backend buffer-file-name)
> ((vc-not-supported
> (message "Warning: %S" err))
> (_
> (message "VC refresh error: %S" err)))))
> --8<---------------cut here---------------end--------------->8---
>
> does not raise the correct message.
Does this work for you?
((setq backend (condition-case err
(vc-backend buffer-file-name)
(vc-not-supported
(message "Warning: %S" err))
(t
(message "VC refresh error: %S" err))))
And you can update the previous (more complex) example similarly,
without pcase.
> Somehow, I probably miss how to correctly propagate errors but the patch
> is, IMHO, the simplest way.
>
>
>> Regarding the rest of the patch, could you explain the change in
>> vc-bzr-state-heuristic? Looking at the code, I figure the idea was to
>> future-proof the parser against some future change in file format, to fall
>> back to (slower) calling the 'bzr' program. Are we somehow certain now this is
>> not needed?
>
> Nothing has really changed. The current pattern is:
>
> --8<---------------cut here---------------start------------->8---
> (condition-case err
> (with-temp-buffer
> ...
> (if (not (looking-at "#bazaar dirstate flat format 3"))
> (vc-bzr-state file) ; Some other unknown format?
> (let* ...)))
> ;; The dirstate file can't be read, or some other problem.
> (error
> (message "Falling back on \"slow\" status detection (%S)" err)
> (vc-bzr-state file)))
> --8<---------------cut here---------------end--------------->8---
>
> where it means ’vc-bzr-state’ is at two places – which is redundant.
> Instead, the pattern,
>
> --8<---------------cut here---------------start------------->8---
> (condition-case err
> (with-temp-buffer
> ...
> (if (not (looking-at "#bazaar dirstate flat format 3"))
> (signal 'error "VC: Bzr dirstate is not flat format 3")
> (let* ...)))
> ;; The dirstate file can't be read, or some other problem.
> (error
> (message "Falling back on \"slow\" status detection (%S)" err)
> (vc-bzr-state file)))
> --8<---------------cut here---------------end--------------->8---
>
> is better because it appears only at one location. Now, knowing if this
> test about the BZR format is relevant or not is another story. :-)
Makes sense now, thanks.
> The patch is just tweaking how the errors are handled, not the logic
> behind. In another patch, this ’vc-bzr-state-heuristic’ could be split;
> as it is done with HG: vc-hg-state calling vc-hg-state-fast falling back
> to vc-hg-state-slow – instead of having the fast (heuristic) included.
Up to you.
> Let me know how to proceed for helping in the review process.
Let's address the raised points first. Thank you.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 27 Sep 2022 19:53:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 27 15:53:06 2022 Received: from localhost ([127.0.0.1]:56859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1odGde-0005F8-DS for submit <at> debbugs.gnu.org; Tue, 27 Sep 2022 15:53:06 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:34751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1odGda-0005EZ-HK for 57407 <at> debbugs.gnu.org; Tue, 27 Sep 2022 15:53:05 -0400 Received: (Authenticated sender: juri@HIDDEN) by mail.gandi.net (Postfix) with ESMTPSA id 78E95240007; Tue, 27 Sep 2022 19:52:50 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Lars Ingebrigtsen <larsi@HIDDEN> Subject: Re: bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-regi?= =?utf-8?Q?stered=E2=80=99?= In-Reply-To: <874jwt59nk.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Tue, 27 Sep 2022 13:39:11 +0200") Organization: LINKOV.NET References: <87lercwb0o.fsf@HIDDEN> <86pmfivzr2.fsf@HIDDEN> <874jwt59nk.fsf@HIDDEN> Date: Tue, 27 Sep 2022 21:50:49 +0300 Message-ID: <868rm4puqi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57407 Cc: Dmitry Gutov <dgutov@HIDDEN>, 57407 <at> debbugs.gnu.org, Simon Tournier <zimon.toutoune@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.7 (-) >> This is a friendly ping about patch #57407 [1]. >> >> 1: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57407> >> >> I would like to know what is the next step and how I can help for >> testing and/or the reviewing process about the patch. > > If Dmitry is busy at the moment, perhaps Juri has some comments here? > Added to the CCs. Sorry, I have no knowledge about this part of VC. My relation with VC was only in adding missing features.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 27 Sep 2022 11:39:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 27 07:39:23 2022 Received: from localhost ([127.0.0.1]:53170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1od8vr-0003lB-0G for submit <at> debbugs.gnu.org; Tue, 27 Sep 2022 07:39:23 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1od8vp-0003kw-45 for 57407 <at> debbugs.gnu.org; Tue, 27 Sep 2022 07:39:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xtEyUv4Srf8iN5HaJ870nPtqRulMBZ16TMz6Y+JQd/c=; b=Yi/sKV29v05ieeoFNL0Cj8AXev CH0x1TGQi5S+sDj/zYQV8bp4ENIvlZcwmc49tkQSNEDgsaBoTzhesBnFw5SKZ4O3vN3NYrRlOzr5t KpPVPNF5N43rgz/fOdxvH8XiFDpyOQSWDobDg394EIDnvotMsclTRuN4RzeXxHQkDPww=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1od8vf-0001Nz-RV; Tue, 27 Sep 2022 13:39:14 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Simon Tournier <zimon.toutoune@HIDDEN> Subject: Re: bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-regi?= =?utf-8?Q?stered=E2=80=99?= In-Reply-To: <86pmfivzr2.fsf@HIDDEN> (Simon Tournier's message of "Mon, 26 Sep 2022 18:58:41 +0200") References: <87lercwb0o.fsf@HIDDEN> <86pmfivzr2.fsf@HIDDEN> X-Now-Playing: Simon & Garfunkel's _Parsley, Sage, Rosemary and Thyme_: "A Poem on the Underground Wall" Date: Tue, 27 Sep 2022 13:39:11 +0200 Message-ID: <874jwt59nk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Simon Tournier <zimon.toutoune@HIDDEN> writes: > This is a friendly ping about patch #57407 [1]. > > 1: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57407> > > I would like to know what is the next step and how I can help for > testing and/or th [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57407 Cc: Juri Linkov <juri@HIDDEN>, 57407 <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 (---) Simon Tournier <zimon.toutoune@HIDDEN> writes: > This is a friendly ping about patch #57407 [1]. > > 1: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57407> > > I would like to know what is the next step and how I can help for > testing and/or the reviewing process about the patch. If Dmitry is busy at the moment, perhaps Juri has some comments here? Added to the CCs.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 26 Sep 2022 16:58:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 26 12:58:56 2022 Received: from localhost ([127.0.0.1]:51672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ocrRX-0001Zg-WF for submit <at> debbugs.gnu.org; Mon, 26 Sep 2022 12:58:56 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:56228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>) id 1ocrRX-0001ZU-0X for 57407 <at> debbugs.gnu.org; Mon, 26 Sep 2022 12:58:55 -0400 Received: by mail-wm1-f48.google.com with SMTP id t4so4947166wmj.5 for <57407 <at> debbugs.gnu.org>; Mon, 26 Sep 2022 09:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date; bh=X/N+gzakuvYCQddkGpxk5xNVXI53HVPj7y1fp41sKCk=; b=MRmk3JHPUdkCfgsPQA7RnODDKMGbPUMYl7JrOrZZx6wKa6fK4CLfJ1p4ZlxeZmCS30 4ZQLi8Bu0nSd4jGkzYLATBjhq0i0Wq2nSJdRPlwrBhqSbbH5pLqrCuyhR1KbtkBVT2iG U3UaQW1JqWf23akHB4B1gXjN48JnPL1x9oHvMHPJ1zTqPX8o/cfK/qVOZ9OIY+w+f+ZF hPqyu73G5zDeAswjvfUILVvgehNt2hEdXKuiT9Co+X8uqvPdtER6kJ1RPEurI6/EjWOV mrR0O/OTz7tRdaSQnTVM6WBaeTHK8Yl1Si/dsE9aeoI/mFS3kcN7JY/daPPmKCaDqFNc ZOKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date; bh=X/N+gzakuvYCQddkGpxk5xNVXI53HVPj7y1fp41sKCk=; b=2uKejsQeToPW4vUBj90di8wcmeKycO1sA2eLiPE+8OgAIRuoxNZm0ESRbPA418SKt5 txi03HJ5AGjg7llH0RZM+XCXUy+tjao/Fp0G1KS4t2du82FVuA0cSN7lVjQjpWxHfJLI WgtuQThTW7m2JG0bnbEUe3OP/y2gFdkD0QSH9bS69L4vEdJVFaH6+Z1xDOGjcpcnayYM 8VWE3S11GwLxuJT4zKINu8+6TKGb1VpxtlvcY+VANdaYNUh6MY5pzLYNAlBzeasl6cPd 9FCK0gVxTPq2xmZgl9zHsVqqwHW8hE1pil50bBysz7W0/3CHSMLx/0sK9/hzyZNmrGgH +aBg== X-Gm-Message-State: ACrzQf36npirGhdWjQ8ImGm+te04V28h1E9d6DCVoZfT4tD2RAx3KFxC F5R6Coqlu0ZytzhGwx9KiR8= X-Google-Smtp-Source: AMsMyM758rLfThQXNZjARg3Yu6ZkzkekWwAX5olMJ2nflzHP9wOho7l1diQlRMfSSKVzyUGUnB7S6Q== X-Received: by 2002:a05:600c:a4c:b0:3b4:fc1b:81 with SMTP id c12-20020a05600c0a4c00b003b4fc1b0081mr15437849wmq.125.1664211529000; Mon, 26 Sep 2022 09:58:49 -0700 (PDT) Received: from lili (roam-nat-fw-prg-194-254-61-41.net.univ-paris-diderot.fr. [194.254.61.41]) by smtp.gmail.com with ESMTPSA id i6-20020a05600c354600b003b47b80cec3sm12485412wmq.42.2022.09.26.09.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 09:58:48 -0700 (PDT) From: Simon Tournier <zimon.toutoune@HIDDEN> To: 57407 <at> debbugs.gnu.org Subject: Re: bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-regi?= =?utf-8?Q?stered=E2=80=99?= References: <87lercwb0o.fsf@HIDDEN> Date: Mon, 26 Sep 2022 18:58:41 +0200 In-Reply-To: <87lercwb0o.fsf@HIDDEN> (Simon Tournier's message of "Thu, 25 Aug 2022 18:20:07 +0200") Message-ID: <86pmfivzr2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) 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: 57407 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 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 (-) Hi, This is a friendly ping about patch #57407 [1]. 1: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D57407> I would like to know what is the next step and how I can help for testing and/or the reviewing process about the patch. On Thu, 25 Aug 2022 at 18:20, Simon Tournier <zimon.toutoune@HIDDEN> wro= te: > Submission (Bug#18481) [0] merged on 2020-08-13 with commit > 991e145450ec8b02865597bc80fd797e39e81f07 [1] aims to: > > =E2=80=9CNotify the user if we errors when querying for registered git fi= les=E2=80=9C > > However, the replacement of =E2=80=99ignore-errors=E2=80=99 by =E2=80=99w= ith-demoted-errors=E2=80=99 > introduces spurious messages. This patch proposes to handle the errors > in a way that: > > 1. the user is still informed (avoid silent error) > 2. improve the messages trying to be more accurate > 3. do it for all the VC backends > > 0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18481 > 1: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D991e145450ec8= b02865597bc80fd797e39e81f07 All the best, simon
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 12 Sep 2022 12:19:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 12 08:19:09 2022
Received: from localhost ([127.0.0.1]:44495 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oXiP6-0006kA-La
for submit <at> debbugs.gnu.org; Mon, 12 Sep 2022 08:19:09 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:38463)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <zimon.toutoune@HIDDEN>) id 1oXiP4-0006jE-37
for 57407 <at> debbugs.gnu.org; Mon, 12 Sep 2022 08:19:06 -0400
Received: by mail-wm1-f46.google.com with SMTP id
n23-20020a7bc5d7000000b003a62f19b453so10851297wmk.3
for <57407 <at> debbugs.gnu.org>; Mon, 12 Sep 2022 05:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding:mime-version:user-agent:message-id
:in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject
:date; bh=U6gYU43BvUkBJl238H248ckP8i1ZAKZyvioFNHj4HFM=;
b=bUiSRttuiEbz/KxJXweqLpQo/3Gz1qJBHhXc+8bkFa+3TZvF3Af0X1jnuaCdPaJaOj
iEmDN7TVBFuTR2yRYtr45DyGwJqLtFBVShoblTzD8rb16q33ywgK2RfcfPBTPqpBbQSY
NUDFb5SfXbIp+iZWRI5p3vSoVHBkintifjxlozR0vlIu0bb9loAUIH5TinyU6caNQkQI
UF+fKhQ/9VRPsylA4KOpqtPQhyhZrz19r6+WvnBN5q5V3yFw0UFKHEDsaoy8ctXC4yFC
0oX+Htxjp450F5TMy7M9hFIM0eUg68RYzi0FyzF10MwoUNdBjhW2u1hl3zD3+EkwnIu0
1nDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:user-agent:message-id
:in-reply-to:date:references:subject:cc:to:from:x-gm-message-state
:from:to:cc:subject:date;
bh=U6gYU43BvUkBJl238H248ckP8i1ZAKZyvioFNHj4HFM=;
b=c6dQFDG9FHKyPP8dXyNsok27NZatCUlz/XC4TklJMAIKe45zovpuj/lzobNJcetgqT
W7lP70NzV0k+Iqffi0GvrbT7jud9YF5gjy4aQPZ/8tUoAzDm8Uet6Vbc5Cai6UrccqyE
kg1kglHCyJiyF+jChqJ1d54NMvWwNgAnS96Orfn9GR02/5gL0biWe+eam6j9OZ9y8p3z
ZRGr9CaZJ45L0cjPGTb78bujYMCOVULd4a0uQK05mtXsjob/6RpUyl6j9Pdo+v6BkDM7
S3UoZpaE4AezfwVyoPqLnj6ZiBG+FBHAml5BgNlt1mC9H7WteCnazhv0KoTX3LP11A+l
c9+g==
X-Gm-Message-State: ACgBeo3tD/r0MWIc6lpu673BJhvwfiFTcuKqADc1nGGA1hmIyApJeyi/
QVUK9OlT4brFeonDM+WiAziAkVIePBM=
X-Google-Smtp-Source: AA6agR4W4FogeIKlQv1eVfAYIsB0YDKNkEg30mRP/PaYxzI+Nz8kxxv//77Lwg8Wdgh6IR2NAsyxBA==
X-Received: by 2002:a05:600c:3544:b0:3b4:6278:8b60 with SMTP id
i4-20020a05600c354400b003b462788b60mr8812513wmq.188.1662985139766;
Mon, 12 Sep 2022 05:18:59 -0700 (PDT)
Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id
bh16-20020a05600c3d1000b003a60ff7c082sm9959997wmb.15.2022.09.12.05.18.59
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 12 Sep 2022 05:18:59 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-regi?=
=?utf-8?Q?stered=E2=80=99?=
References: <87lercwb0o.fsf@HIDDEN>
<f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN>
Date: Mon, 12 Sep 2022 14:18:52 +0200
In-Reply-To: <f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN> (Dmitry Gutov's
message of "Mon, 12 Sep 2022 04:08:23 +0300")
Message-ID: <87czc0eqfn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
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: 57407
Cc: 57407 <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 (-)
Hi,
Thanks for your comments.
On lun., 12 sept. 2022 at 04:08, Dmitry Gutov <dgutov@HIDDEN> wrote:
> Do I take this right that the main purpose of the patch is to have the "E=
rror:
> ..." messages replaced with "Warning: ..."?
Somehow yes. More explicitly, replace =E2=80=9CError: <useless message>=E2=
=80=9D with
=E2=80=9CWarning: <more helpful>=E2=80=9D.
> But you also add a bunch of re-signaling code like
>
> + (let ((state (condition-case err
> + (vc-bzr-state-heuristic file)
> + (error (signal (car err) (cdr err))))))
>
> What is the idea behind this? Why not just keep the call?
What do you mean? You need to catch the error and propagates it.
If the heuristic fails in vc-bzr-state-heuristic, then =E2=80=99vc-bzr-stat=
e=E2=80=99 is
called, which itself then calls =E2=80=99vc-bzr-status=E2=80=99. This stat=
us function
can signal an error and it requires to be raised again.
> And in vc-svn-registered, for example. You re-signal whatever error is ca=
ught,
> without any alternative. Do we need the condition-case there at all, then?
Yes, you need to re-throw the error to propagate it. See
=E2=80=99(elisp)Handling Errors=E2=80=99:
Sometimes it is necessary to re-throw a signal caught by
=E2=80=98condition-case=E2=80=99, for some outer-level handler to catc=
h. Here=E2=80=99s
how to do that:
(signal (car err) (cdr err))
where =E2=80=98err=E2=80=99 is the error description variable, the fir=
st argument
to =E2=80=98condition-case=E2=80=99 whose error condition you want to =
re-throw.
Or I am missing a point. :-)
> Furthermore, we'll have to examine the resulting effect on the behavior of
> various backend methods. Apparently, up until now vc-svn-registered never
> signaled an error (swallowed all of them). And now whatever callers it ha=
s,
> will need to handle possible errors.
I think it is what this patch is doing: handle possible errors by the
=E2=80=99vc-<backend>-registered=E2=80=99 callers.
> It's probably fine, though. vc-backend is a more popular function, and it
> seems not much is changing for it, since, for some reason, vc-refresh-sta=
te
> wrapped its call in with-demoted-errors anyway.
For what my opinion is worth, the commit
991e145450ec8b02865597bc80fd797e39e81f07 =E2=80=93 which replaces
=E2=80=99ignore-errors=E2=80=99 with =E2=80=99with-demoted-errors=E2=80=99 =
only for the Git backend =E2=80=93 is
a valuable idea but incorrectly implemented. This patch is an attempt
to improve the situation.
> But I think we have other callers of it in-tree, and not all of them guard
> with with-demoted-errors or condition-case. What do you think we should do
> with them?
Could you be more specific about these =E2=80=9Cother callers=E2=80=9D? Fr=
om my
understanding, =E2=80=99vc-<backend>-registered=E2=80=99 is called by =E2=
=80=99vc-registered=E2=80=99
and this patch handles this case; even =E2=80=99vc-registered=E2=80=99 is n=
ot modified
by this patch and the handler happens in =E2=80=99vc-refresh-state=E2=80=99.
Moreover,
--8<---------------cut here---------------start------------->8---
$ for backend in svn git hg ;do ag --elisp vc-${backend}-registered ;done
lisp/ldefs-boot.el
33455: (defun vc-svn-registered (f)
33462: (vc-svn-registered f))))
lisp/vc/vc-svn.el
110:;; vc-svn-registered, but we want the value to be compiled at startup, =
not
133:;;;###autoload (defun vc-svn-registered (f)
140:;;;###autoload (vc-svn-registered f))))
142:(defun vc-svn-registered (file)
242: (vc-svn-registered file)
lisp/ldefs-boot.el
33399: (defun vc-git-registered (file)
33404: (vc-git-registered file))))
lisp/vc/vc-git.el
244:;;;###autoload (defun vc-git-registered (file)
249:;;;###autoload (vc-git-registered file))))
251:(defun vc-git-registered (file)
lisp/ldefs-boot.el
33410: (defun vc-hg-registered (file)
33415: (vc-hg-registered file))))
lisp/vc/vc-hg.el
85:;; vc-hg-registered and vc-hg-state
198:;;;###autoload (defun vc-hg-registered (file)
203:;;;###autoload (vc-hg-registered file))))
206:(defun vc-hg-registered (file)
--8<---------------cut here---------------end--------------->8---
means that another caller is =E2=80=99vc-svn-working-revision=E2=80=99 used=
by,
--8<---------------cut here---------------start------------->8---
(defun vc-working-revision (file &optional backend)
"Return the repository version from which FILE was checked out.
If FILE is not registered, this function always returns nil."
(or (vc-file-getprop file 'vc-working-revision)
(progn
(setq backend (or backend (vc-backend file)))
(when backend
(vc-file-setprop file 'vc-working-revision
(vc-call-backend
backend 'working-revision file))))))
--8<---------------cut here---------------end--------------->8---
Therefore, =E2=80=99vc-svn-working-revision=E2=80=99 should also be guarded=
with
=E2=80=99condition-case=E2=80=99 and display an appropriate message, indeed.
>> It is probably an abuse of =E2=80=99pcase=E2=80=99. Is =E2=80=99cond=E2=
=80=99 better here? Last,
>> I have not found in the documentation how to differentiate what it is
>> raised depending on the error type, hence the =E2=80=99pcase=E2=80=99.
>
> I think you just need to write the specific error type instead of 'error'=
in
> the handler clause.
Maybe I am missing a point about error handling and how they propagate.
If I consider this change removing =E2=80=99pcase=E2=80=99 and write the sp=
ecific error
as you are suggesting,
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index 778d1139fc..39ad27f2fd 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -361,15 +361,13 @@ vc-do-command
(let ((buffer-undo-list t))
(condition-case err
(setq status (apply #'process-file command nil t nil squeezed))
- (error
- (pcase (car err)
- ('file-missing
- (if (string=3D (cadr err) "Searching for program")
- ;; The most probable is the lack of the backend bi=
nary.
- (signal 'vc-not-supported (cdr err))
- (signal (car err) (cdr err))))
- (_
- (signal (car err) (cdr err)))))))
+ ((file-missing
+ (if (string=3D (cadr err) "Searching for program")
+ ;; The most probable is the lack of the backend bina=
ry.
+ (signal 'vc-not-supported (cdr err))
+ (signal (car err) (cdr err))))
+ (_
+ (signal (car err) (cdr err))))))
(when (and (not (eq t okstatus))
(or (not (integerp status))
(and okstatus (< okstatus status))))
--8<---------------cut here---------------end--------------->8---
then instead of,
--8<---------------cut here---------------start------------->8---
Warning: (vc-not-supported "Searching for program" "No such file or directo=
ry" "git")
--8<---------------cut here---------------end--------------->8---
the report is,
--8<---------------cut here---------------start------------->8---
VC refresh error: (void-function _)
--8<---------------cut here---------------end--------------->8---
Well, I do not know how to avoid the =E2=80=99pcase=E2=80=99 here to correc=
tly propagate
the errors.
About the other =E2=80=99pcase=E2=80=99, this code,
--8<---------------cut here---------------start------------->8---
((setq backend (condition-case err
(vc-backend buffer-file-name)
((vc-not-supported
(message "Warning: %S" err))
(_
(message "VC refresh error: %S" err)))))
--8<---------------cut here---------------end--------------->8---
does not raise the correct message.
Somehow, I probably miss how to correctly propagate errors but the patch
is, IMHO, the simplest way.
> Regarding the rest of the patch, could you explain the change in
> vc-bzr-state-heuristic? Looking at the code, I figure the idea was to
> future-proof the parser against some future change in file format, to fall
> back to (slower) calling the 'bzr' program. Are we somehow certain now th=
is is
> not needed?
Nothing has really changed. The current pattern is:
--8<---------------cut here---------------start------------->8---
(condition-case err
(with-temp-buffer
...
(if (not (looking-at "#bazaar dirstate flat format 3"))
(vc-bzr-state file) ; Some other unknown format?
(let* ...)))
;; The dirstate file can't be read, or some other problem.
(error
(message "Falling back on \"slow\" status detection (%S)" err)
(vc-bzr-state file)))
--8<---------------cut here---------------end--------------->8---
where it means =E2=80=99vc-bzr-state=E2=80=99 is at two places =E2=80=93 wh=
ich is redundant.
Instead, the pattern,
--8<---------------cut here---------------start------------->8---
(condition-case err
(with-temp-buffer
...
(if (not (looking-at "#bazaar dirstate flat format 3"))
(signal 'error "VC: Bzr dirstate is not flat format 3")
(let* ...)))
;; The dirstate file can't be read, or some other problem.
(error
(message "Falling back on \"slow\" status detection (%S)" err)
(vc-bzr-state file)))
--8<---------------cut here---------------end--------------->8---
is better because it appears only at one location. Now, knowing if this
test about the BZR format is relevant or not is another story. :-)
The patch is just tweaking how the errors are handled, not the logic
behind. In another patch, this =E2=80=99vc-bzr-state-heuristic=E2=80=99 co=
uld be split;
as it is done with HG: vc-hg-state calling vc-hg-state-fast falling back
to vc-hg-state-slow =E2=80=93 instead of having the fast (heuristic) includ=
ed.
Let me know how to proceed for helping in the review process.
All the best,
simon
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 12 Sep 2022 01:08:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 11 21:08:34 2022
Received: from localhost ([127.0.0.1]:43757 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oXXw9-0005so-WA
for submit <at> debbugs.gnu.org; Sun, 11 Sep 2022 21:08:34 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:55135)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1oXXw7-0005sW-4D
for 57407 <at> debbugs.gnu.org; Sun, 11 Sep 2022 21:08:32 -0400
Received: by mail-wm1-f48.google.com with SMTP id az6so6149792wmb.4
for <57407 <at> debbugs.gnu.org>; Sun, 11 Sep 2022 18:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding:in-reply-to:from:references:to
:content-language:subject:user-agent:mime-version:date:message-id
:sender:from:to:cc:subject:date;
bh=LmF3+DY8hXZQJTi4E73jAJDca2Jw4wbgo+88OKpIxNU=;
b=fWPNWQBkWlGR5srGYUYUleu1R2vNND4cpsMduzqJt/2ipiJ5D/2lADWjNx88D5fPma
Cl4AFb6sP0n940J+sIn/vh0niKS/+hXmX1omhGds6dvq/chanqQBhdEPNp75N5ZI1S/9
50KT1YyL0nrmwwHCk2/FZjo9D4asz/uNKDyqcihvHZS+/Uv1dY4Tmn8u7nCfwVAQIoaP
sfPvmHxS3cUmKDldJYCYTTXDnSAz2yG8FPGs71PFStKwLDMa9+EaFc3VFFhICgynshV7
WneDHIAr+NYaTixPNqoNTBZJrYXruAnPAb8Z8Yzuj7G/SVQOSvNPhVTJxEf3iPcCikoB
GTNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:in-reply-to:from:references:to
:content-language:subject:user-agent:mime-version:date:message-id
:sender:x-gm-message-state:from:to:cc:subject:date;
bh=LmF3+DY8hXZQJTi4E73jAJDca2Jw4wbgo+88OKpIxNU=;
b=cuO+wJGr1ANHPdzDPDe018l+VtkYcboNtrAMqgU126hiFv8WgKnHaLDiZO3AZtFXUu
pZ2gVriF7XrwpsZiLUUv8n1m45EI027M8Lg6SQmgQPPtlpxiuBv7ogxkf3dS81oPRdtE
hlkSJDAjDwp3PhtJ9L3X5Hzln0DMguSCVJUrMG64ouicixgjb44NlbKpEywIdEBy/2R2
ulM0HmXOKGrrjyKVFF1TUpRdqoe+zAi/DJvVMMKAa3qbM3pYLzM0hvW9LDS5Jwy22WDX
rbuMGTclBKQ88RElVcAMxmnA2F+VZeGAQHpiZfOIaDfTt5mkGAHzfffHN+IVnJEkB2C6
UPjQ==
X-Gm-Message-State: ACgBeo0h8aPyfychvzxgMC4UOiWahLUsi8wVvpkEyjVeyGEHikAWOOeP
8mlqZRLYQRJ7t9pafjiVSY0=
X-Google-Smtp-Source: AA6agR7ityX+4OKS0Fda3AIEmpm3cMFwRzBjLPnsQBZxvB+CBUYCkbMmNEpkm3esRDfHwYV7dL+c5Q==
X-Received: by 2002:a05:600c:4ec7:b0:3a8:4622:ad27 with SMTP id
g7-20020a05600c4ec700b003a84622ad27mr12806371wmq.88.1662944905109;
Sun, 11 Sep 2022 18:08:25 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
by smtp.googlemail.com with ESMTPSA id
g14-20020a05600c4ece00b003a4c6e67f01sm8733625wmq.6.2022.09.11.18.08.24
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 11 Sep 2022 18:08:24 -0700 (PDT)
Message-ID: <f0750a8d-cbfb-0a49-d18c-40c3fd1122b2@HIDDEN>
Date: Mon, 12 Sep 2022 04:08:23 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: =?UTF-8?B?UmU6IGJ1ZyM1NzQwNzogW1BBVENIXSBIYW5kbGUgZXJyb3Igb2Yg4oCZ?=
=?UTF-8?Q?vc-registered=e2=80=99?=
Content-Language: en-US
To: Simon Tournier <zimon.toutoune@HIDDEN>, 57407 <at> debbugs.gnu.org
References: <87lercwb0o.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87lercwb0o.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 57407
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.5 (/)
Hi!
On 25.08.2022 19:20, Simon Tournier wrote:
> Hi,
>
> Submission (Bug#18481) [0] merged on 2020-08-13 with commit
> 991e145450ec8b02865597bc80fd797e39e81f07 [1] aims to:
>
> “Notify the user if we errors when querying for registered git files“
>
> However, the replacement of ’ignore-errors’ by ’with-demoted-errors’
> introduces spurious messages. This patch proposes to handle the errors
> in a way that:
>
> 1. the user is still informed (avoid silent error)
> 2. improve the messages trying to be more accurate
> 3. do it for all the VC backends
>
> 0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18481
> 1: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=991e145450ec8b02865597bc80fd797e39e81f07
>
>
>
> First, let compare the previous situation with the patched one. If the
> user runs ’find-file’ in a Git repository without having installed the
> Git binary, then Emacs complains and the error is misleading.
> Reproducer:
>
> --8<---------------cut here---------------start------------->8---
> $ which git
> which: no git in …
> $ mkdir -p /tmp/Git/.git
> $ emacs -q --batch --eval="(find-file \"/tmp/Git/foo\")"
> Error: (file-missing "Searching for program" "No such file or directory" "git")
> Package vc-mtn is deprecated
> --8<---------------cut here---------------end--------------->8---
>
> Not having a working Git installation is not an error for opening one
> file belonging to a folder containing a ’.git’ subdirectory. For
> instance, if an user processes many files reporting many messages, then
> it seems hard to locate the real error, if any.
Do I take this right that the main purpose of the patch is to have the
"Error: ..." messages replaced with "Warning: ..."?
> Moreover, the messages are inconsistent depending on the VC backend;
> from nothing reported to a backtrace.
>
> --8<---------------cut here---------------start------------->8---
> $ mkdir -p /tmp/Bzr/.bzr
> $ emacs -q --batch --eval="(find-file \"/tmp/Bzr/foo\")"
> Error: (file-missing "Searching for program" "No such file or directory" "bzr")
> Error: (file-missing "Searching for program" "No such file or directory" "bzr")
>
> Error: file-missing ("Searching for program" "No such file or directory" "bzr")
>
> [...]
>
> Searching for program: No such file or directory, bzr
> --8<---------------cut here---------------end--------------->8---
>
> Considering the patch, it would become:
>
> --8<---------------cut here---------------start------------->8---
> $ emacs -q --batch --eval="(find-file \"/tmp/Git/foo\")"
> Warning: (vc-not-supported "Searching for program" "No such file or directory" "git")
>
> $ emacs -q --batch --eval="(find-file \"/tmp/Bzr/foo\")"
> Falling back on "slow" status detection ((error . "VC: Bzr dirstate is not flat format 3"))
> Warning: (vc-not-supported "Searching for program" "No such file or directory" "bzr")
> --8<---------------cut here---------------end--------------->8---
>
> and all the VC backends report similarly when something fails.
Some better consistency would be nice indeed.
> Second, I have tested various configurations using Guix (65cabb0) and
> also the Emacs test suite is passing. However, note that a) I barely
> use VC so b) I am lacking imagination for testing scenarii where the
> bubble error could wrongly propagate and thus would provide an
> unexpected behavior. Especially with remote as Tramp allows.
>
>
> Third, I do not know if it is the correct way for catching the errors.
> The core of the change is:
>
> --8<---------------cut here---------------start------------->8---
> lisp/vc/vc-dispatcher.el (vc-do-command):
>
> (condition-case err
> (setq status (apply #'process-file command nil t nil squeezed))
> (error
> (pcase (car err)
> ('file-missing
> (if (string= (cadr err) "Searching for program")
> ;; The most probable is the lack of the backend binary.
> (signal 'vc-not-supported (cdr err))
> (signal (car err) (cdr err))))
> (_
> (signal (car err) (cdr err))))))
>
> lisp/vc/vc-hooks.el (vc-refresh-state):
>
> (condition-case err
> (vc-backend buffer-file-name)
> (error
> (pcase (car err)
> ('vc-not-supported
> (message "Warning: %S" err))
> (_
> (message "VC refresh error: %S" err)))
> nil))
> --8<---------------cut here---------------end--------------->8---
>
> and the rest of the change is just bubble error propagation from this
> ’vc-do-command’ to this ’vc-refresh-state’.
This general idea seems reasonable.
But you also add a bunch of re-signaling code like
+ (let ((state (condition-case err
+ (vc-bzr-state-heuristic file)
+ (error (signal (car err) (cdr err))))))
What is the idea behind this? Why not just keep the call?
And in vc-svn-registered, for example. You re-signal whatever error is
caught, without any alternative. Do we need the condition-case there at
all, then?
Furthermore, we'll have to examine the resulting effect on the behavior
of various backend methods. Apparently, up until now vc-svn-registered
never signaled an error (swallowed all of them). And now whatever
callers it has, will need to handle possible errors.
It's probably fine, though. vc-backend is a more popular function, and
it seems not much is changing for it, since, for some reason,
vc-refresh-state wrapped its call in with-demoted-errors anyway.
But I think we have other callers of it in-tree, and not all of them
guard with with-demoted-errors or condition-case. What do you think we
should do with them?
> It is probably an abuse of ’pcase’. Is ’cond’ better here? Last,
> I have not found in the documentation how to differentiate what it is
> raised depending on the error type, hence the ’pcase’.
I think you just need to write the specific error type instead of
'error' in the handler clause.
Regarding the rest of the patch, could you explain the change in
vc-bzr-state-heuristic? Looking at the code, I figure the idea was to
future-proof the parser against some future change in file format, to
fall back to (slower) calling the 'bzr' program. Are we somehow certain
now this is not needed?
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Received: (at 57407) by debbugs.gnu.org; 8 Sep 2022 15:25:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 08 11:25:53 2022 Received: from localhost ([127.0.0.1]:59901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oWJPd-0006EJ-C5 for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 11:25:53 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:33536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>) id 1oWJPb-0006Dz-JJ for 57407 <at> debbugs.gnu.org; Thu, 08 Sep 2022 11:25:51 -0400 Received: by mail-wr1-f54.google.com with SMTP id k9so26728361wri.0 for <57407 <at> debbugs.gnu.org>; Thu, 08 Sep 2022 08:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:to:from:from:to:cc:subject:date; bh=KDDtvjqyUxDtAXNNFeWwbyzO4I7hbjo0XUlljUkOMK4=; b=aE3Z+BVzZYOERAYdLqquhPwaED94yhSdyoBNdl+Pd0tdhaxZX0xV5Sdp5zpkR3LWhI PiyWXyyEXT0ZddYsprxZVf6SPjTf+lFapBVy3gMVjkPDZ+JxO4Oq6PkUnvrSjtfAOCMQ +SufEFMfC+ItEh6XlBgCFIzc9CSAlL8S5ihokIp1eMin0HNvz+z4zrJcAWl57G9SocAq d8v66fHk40yjTql2aNwxUt6lSi3MlCWhom9rBd2UIQUSbZWFbPCNXcoodqjAk739T71e NYU7ynSrQwLeniprYlPi5FX+1FQSJiemZpNcwMAiagHD/FZ0UkznaUVION6dA4ahvp0s YbLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:to:from:x-gm-message-state:from :to:cc:subject:date; bh=KDDtvjqyUxDtAXNNFeWwbyzO4I7hbjo0XUlljUkOMK4=; b=aH41nbHtgn0mHrWYVPb+jT1spRk1JCN28Knvdojr9dwcTKOFeVET+wdHquNtd5bxME 8T5dNkxFYmk0rkH+4kO1xb5PwEnlA6PG0xAeBalhWa3Ddg8bn0pUmyMc6V3WhS9cn+xT FG2i0gbTGOP865jjQ6lH1BZ0thQD+nm/AoTHuVm75LbnyCnrxciUQDjpsBDaWTNjAGBg t9ZYjGKGy+lWh8bbg7GiV8wn3EnzK2t+D6p/hcVVINMA0u6HC+EfqczfMQDq5/poh8sU yb2bYsiq1SqrI7G8CBFWUHLRN76RIB4YsaMZ7ALfWJg1tHB3xnj3Y94TWUszufPeZu4d IM9g== X-Gm-Message-State: ACgBeo1T2GuOB+TM4c5Qx5wh0hnKCwjOCLhs2gPOq1CdObt15fEU1cOu cNCCBI1+868aGpWDeK3Lvra6/QIBb1w= X-Google-Smtp-Source: AA6agR66F21+v9byni0PD9Y2wPIZRY6QlkBIh/BEpSIBNmvO5bjUXee7JFagLpSEcoAH5bquNVmGAg== X-Received: by 2002:a05:6000:18a3:b0:21f:d6a4:1aec with SMTP id b3-20020a05600018a300b0021fd6a41aecmr5526889wri.468.1662650745614; Thu, 08 Sep 2022 08:25:45 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id fc15-20020a05600c524f00b003a5260b8392sm3576239wmb.23.2022.09.08.08.25.44 for <57407 <at> debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 08:25:45 -0700 (PDT) From: Simon Tournier <zimon.toutoune@HIDDEN> To: 57407 <at> debbugs.gnu.org Subject: Copyright Assignment done (was bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-registered=E2=80=99=29?= References: <87lercwb0o.fsf@HIDDEN> Date: Thu, 08 Sep 2022 17:25:31 +0200 In-Reply-To: <87lercwb0o.fsf@HIDDEN> (Simon Tournier's message of "Thu, 25 Aug 2022 18:20:07 +0200") Message-ID: <87bkrplwgk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) 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: 57407 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 (-) Hi, On jeu., 25 ao=C3=BBt 2022 at 18:20, Simon Tournier <zimon.toutoune@HIDDEN= om> wrote: > PS: If this patch makes sense for inclusion, then let me know and I will > complete the Copyright Assignment process. Just to let you know that now the Copyright Assignment process is complete. Cheers, simon
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.Lars Ingebrigtsen <larsi@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 57407) by debbugs.gnu.org; 4 Sep 2022 21:54:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 04 17:54:48 2022
Received: from localhost ([127.0.0.1]:45852 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oUxZo-0005p2-Bn
for submit <at> debbugs.gnu.org; Sun, 04 Sep 2022 17:54:48 -0400
Received: from quimby.gnus.org ([95.216.78.240]:33088)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1oUxZm-0005om-K4
for 57407 <at> debbugs.gnu.org; Sun, 04 Sep 2022 17:54:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
:Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=LWgjVGfPzOx19Jd9tRp0wBMYgv7GtD9Ho0y8TBrjcNY=; b=aFZdXbcB0bk+I/kEzN8M+XeqDp
IDDh5J7CBibU6pJrfQBwLQwU6aYsBpH+9t1kGRX3LW+IoPw2bIcOWq8C+BK0uG1pXPh7M3H6mvWLy
gi6GOcoSwNHY3E3F9iD1ePloLgmA34+k7UgtMOjMw7RPSATEW0jh5k2hEwNQ/RM+UIrI=;
Received: from [84.212.220.105] (helo=joga)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1oUxZd-00034h-TV; Sun, 04 Sep 2022 23:54:39 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Simon Tournier <zimon.toutoune@HIDDEN>
Subject: Re: bug#57407: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-regi?=
=?utf-8?Q?stered=E2=80=99?=
In-Reply-To: <87lercwb0o.fsf@HIDDEN> (Simon Tournier's message of "Thu, 25
Aug 2022 18:20:07 +0200")
References: <87lercwb0o.fsf@HIDDEN>
X-Now-Playing: Neil Young's _Harvest_: "A Man Needs A Maid"
Date: Sun, 04 Sep 2022 23:54:36 +0200
Message-ID: <87wnai6c0z.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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
@@CONTACT_ADDRESS@@ for details.
Content preview: Simon Tournier <zimon.toutoune@HIDDEN> writes: > However,
the replacement of ’ignore-errors’ by ’with-demoted-errors’ > introduces
spurious messages. This patch proposes to handle the errors > in a way that:
> > 1. the user is still inform [...]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57407
Cc: 57407 <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 (---)
Simon Tournier <zimon.toutoune@HIDDEN> writes:
> However, the replacement of =E2=80=99ignore-errors=E2=80=99 by =E2=80=99w=
ith-demoted-errors=E2=80=99
> introduces spurious messages. This patch proposes to handle the errors
> in a way that:
>
> 1. the user is still informed (avoid silent error)
> 2. improve the messages trying to be more accurate
> 3. do it for all the VC backends
Makes sense to me. Perhaps Dmitry has some comments; added to the CCs.
bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 25 Aug 2022 16:20:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 25 12:20:42 2022
Received: from localhost ([127.0.0.1]:51110 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oRFay-0002kd-SB
for submit <at> debbugs.gnu.org; Thu, 25 Aug 2022 12:20:41 -0400
Received: from lists.gnu.org ([209.51.188.17]:44728)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <zimon.toutoune@HIDDEN>) id 1oRFav-0002kU-0U
for submit <at> debbugs.gnu.org; Thu, 25 Aug 2022 12:20:39 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56076)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <zimon.toutoune@HIDDEN>)
id 1oRFam-0002vc-TH
for bug-gnu-emacs@HIDDEN; Thu, 25 Aug 2022 12:20:36 -0400
Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:39553)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <zimon.toutoune@HIDDEN>)
id 1oRFah-00064v-9G
for bug-gnu-emacs@HIDDEN; Thu, 25 Aug 2022 12:20:27 -0400
Received: by mail-wr1-x42d.google.com with SMTP id az27so5254376wrb.6
for <bug-gnu-emacs@HIDDEN>; Thu, 25 Aug 2022 09:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:message-id:date:subject:to:from:from:to:cc;
bh=o+iVlyF7wW8w7iopzv4YWEGKpAC7yv+gzfs98yB0nV0=;
b=E4GHSedfCEcaaywE7O2t7BhiSJarccgJnlj1RSaJygpHp1VdCRnhLVwDH0h3GJ78zO
Ct/fpCNSkxET92cCkIbnksA2dYMIPgJfudor79lwVZt6q2OBC5AvT7M62E8YukBo5/vF
Yx56v/iD8O11DJOdAk87ENqiJ5nGnc+dpZup84hEo3Im+1mjl6EUdSBRGi2WEwIZztDC
zctyGxUFUy9HH9heLNRs08iHbuemwS5Me3aUAAi/FhFuTVObVShwlXJgJryTVRcI1n+7
xzWZDU3j96rLNhvUNtOcLPgZ1UyqTrn/CGPb41wN/jXaOu9jjyBjlWy51JAVaOTVT7GV
8bew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=mime-version:message-id:date:subject:to:from:x-gm-message-state
:from:to:cc;
bh=o+iVlyF7wW8w7iopzv4YWEGKpAC7yv+gzfs98yB0nV0=;
b=ixG6HeqUzomgOtaTt9EdXp9nLKdvWj2H0XwjwGCrdQyeMV+R8gHtLUcIFbLDTKvHag
OY0+13w9Nf6tVaehV9N8rP2tOExscB7nNPunBnJk8+6pp0jTmOaEoXQKGG4BKfDsTJeK
dyPVA1C+3yjiD2qPDyEOM1SXZzb+uXUII4F621wi0QRZDgcNVaIgcKjaDdJaIxzbXyjD
iP0OZNRYu3RjvEJg7KCfZ1oHg/A4h8TMEOp4tWuFuMF605QjHhq+tbEahM4ZnL81MFyt
s5vevNC1qhFPZdPY13n09qBmiko5Y3JJCwmPoccB+KZQHM0WyiXfLRXaHTN6Iha8tSh5
U8eQ==
X-Gm-Message-State: ACgBeo3OXlPlJ85o0P+6puPu6HAJNZg3l6yYIhlpjAsKJi+RnUU3rSVg
eOjVto3sZtL5ZzunEpD7CXnktlIeOms=
X-Google-Smtp-Source: AA6agR48zyZNss7BEY/5Z+6aPF5+ir4kpUBf9RATUyXVerM8ZHB0L4Jd2a+AaR6zaXxTj83W4yUEGA==
X-Received: by 2002:adf:e78c:0:b0:225:2de2:940d with SMTP id
n12-20020adfe78c000000b002252de2940dmr2639936wrm.686.1661444418910;
Thu, 25 Aug 2022 09:20:18 -0700 (PDT)
Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id
v2-20020a5d6b02000000b0021e30e9e44asm19701949wrw.53.2022.08.25.09.20.17
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 25 Aug 2022 09:20:17 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Handle error of =?utf-8?Q?=E2=80=99vc-registered=E2=80=99?=
Date: Thu, 25 Aug 2022 18:20:07 +0200
Message-ID: <87lercwb0o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::42d;
envelope-from=zimon.toutoune@HIDDEN; helo=mail-wr1-x42d.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
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: -2.3 (--)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
Submission (Bug#18481) [0] merged on 2020-08-13 with commit
991e145450ec8b02865597bc80fd797e39e81f07 [1] aims to:
=E2=80=9CNotify the user if we errors when querying for registered git file=
s=E2=80=9C
However, the replacement of =E2=80=99ignore-errors=E2=80=99 by =E2=80=99wit=
h-demoted-errors=E2=80=99
introduces spurious messages. This patch proposes to handle the errors
in a way that:
1. the user is still informed (avoid silent error)
2. improve the messages trying to be more accurate
3. do it for all the VC backends
0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18481
1: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D991e145450ec8b0=
2865597bc80fd797e39e81f07
First, let compare the previous situation with the patched one. If the
user runs =E2=80=99find-file=E2=80=99 in a Git repository without having in=
stalled the
Git binary, then Emacs complains and the error is misleading.
Reproducer:
--8<---------------cut here---------------start------------->8---
$ which git
which: no git in =E2=80=A6
$ mkdir -p /tmp/Git/.git
$ emacs -q --batch --eval=3D"(find-file \"/tmp/Git/foo\")"
Error: (file-missing "Searching for program" "No such file or directory" "g=
it")
Package vc-mtn is deprecated
--8<---------------cut here---------------end--------------->8---
Not having a working Git installation is not an error for opening one
file belonging to a folder containing a =E2=80=99.git=E2=80=99 subdirectory=
. For
instance, if an user processes many files reporting many messages, then
it seems hard to locate the real error, if any.
Moreover, the messages are inconsistent depending on the VC backend;
from nothing reported to a backtrace.
--8<---------------cut here---------------start------------->8---
$ mkdir -p /tmp/Bzr/.bzr
$ emacs -q --batch --eval=3D"(find-file \"/tmp/Bzr/foo\")"
Error: (file-missing "Searching for program" "No such file or directory" "b=
zr")
Error: (file-missing "Searching for program" "No such file or directory" "b=
zr")
Error: file-missing ("Searching for program" "No such file or directory" "b=
zr")
[...]
Searching for program: No such file or directory, bzr
--8<---------------cut here---------------end--------------->8---
Considering the patch, it would become:
--8<---------------cut here---------------start------------->8---
$ emacs -q --batch --eval=3D"(find-file \"/tmp/Git/foo\")"
Warning: (vc-not-supported "Searching for program" "No such file or directo=
ry" "git")
$ emacs -q --batch --eval=3D"(find-file \"/tmp/Bzr/foo\")"
Falling back on "slow" status detection ((error . "VC: Bzr dirstate is not =
flat format 3"))
Warning: (vc-not-supported "Searching for program" "No such file or directo=
ry" "bzr")
--8<---------------cut here---------------end--------------->8---
and all the VC backends report similarly when something fails.
Second, I have tested various configurations using Guix (65cabb0) and
also the Emacs test suite is passing. However, note that a) I barely
use VC so b) I am lacking imagination for testing scenarii where the
bubble error could wrongly propagate and thus would provide an
unexpected behavior. Especially with remote as Tramp allows.
Third, I do not know if it is the correct way for catching the errors.
The core of the change is:
--8<---------------cut here---------------start------------->8---
lisp/vc/vc-dispatcher.el (vc-do-command):
(condition-case err
(setq status (apply #'process-file command nil t nil squeezed))
(error
(pcase (car err)
('file-missing
(if (string=3D (cadr err) "Searching for program")
;; The most probable is the lack of the backend bin=
ary.
(signal 'vc-not-supported (cdr err))
(signal (car err) (cdr err))))
(_
(signal (car err) (cdr err))))))
lisp/vc/vc-hooks.el (vc-refresh-state):
(condition-case err
(vc-backend buffer-file-name)
(error
(pcase (car err)
('vc-not-supported
(message "Warning: %S" err))
(_
(message "VC refresh error: %S" err)))
nil))
--8<---------------cut here---------------end--------------->8---
and the rest of the change is just bubble error propagation from this
=E2=80=99vc-do-command=E2=80=99 to this =E2=80=99vc-refresh-state=E2=80=99.
It is probably an abuse of =E2=80=99pcase=E2=80=99. Is =E2=80=99cond=E2=80=
=99 better here? Last,
I have not found in the documentation how to differentiate what it is
raised depending on the error type, hence the =E2=80=99pcase=E2=80=99.
I hope all this is helpful and going in the right direction for
improving the reported messages. If not, let me know what could be
better.
Cheers,
simon
PS: If this patch makes sense for inclusion, then let me know and I will
complete the Copyright Assignment process.
Simon Tournier (1):
Handle error of 'vc-registered'
lisp/vc/vc-bzr.el | 82 ++++++++++++++++++++--------------------
lisp/vc/vc-dispatcher.el | 12 +++++-
lisp/vc/vc-git.el | 24 +++++++-----
lisp/vc/vc-hg.el | 13 +++----
lisp/vc/vc-hooks.el | 11 +++++-
lisp/vc/vc-svn.el | 5 +--
6 files changed, 84 insertions(+), 63 deletions(-)
base-commit: 1007800a5994ac49b6bc9cd7528edb2d709d2031
--=20
2.36.0
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0001-Handle-error-of-vc-registered.patch
Content-Description: the.patch
From befbe14487c1ba4ee2a98edb8dc6ef1f111d9fbd Mon Sep 17 00:00:00 2001
From: Simon Tournier <zimon.toutoune@HIDDEN>
Date: Thu, 25 Aug 2022 02:47:03 +0200
Subject: [PATCH 1/1] Handle error of 'vc-registered'
This follows up commit 991e145450ec8b02865597bc80fd797e39e81f07:
2020-08-13 "Notify the user if we errors when querying for registered
git files"
closing Bug#18481.
* lisp/vc/vc-bzr.el (vc-bzr-state-heuristic): Raise an error for
unknown Bazaar dirstate format.
(vc-bzr-registered): Catch the error.
(vc-bzr-status): Tweak error catch.
* lisp/vc/vc-dispatcher.el (vc-do-command): Catch errors of command
run synchronously.
* lisp/vc/vc-git.el (vc-git-registered): Raise the errors reported by
'vc-git-command'.
* lisp/vc/vc-hg.el (vc-hg-registered): Avoid unnecessary calls by
directly call specialized 'vc-hg-state', replace generic
'process-file' by specialized 'vc-hg-command', do not ignore errors.
* lisp/vc/vc-hooks.el (vc-refresh-state): Notify accordindly to the
failure.
* lisp/vc/vc-svn.el (vc-svn-registered): Raise the errors.
---
lisp/vc/vc-bzr.el | 82 ++++++++++++++++++++--------------------
lisp/vc/vc-dispatcher.el | 12 +++++-
lisp/vc/vc-git.el | 24 +++++++-----
lisp/vc/vc-hg.el | 13 +++----
lisp/vc/vc-hooks.el | 11 +++++-
lisp/vc/vc-svn.el | 5 +--
6 files changed, 84 insertions(+), 63 deletions(-)
diff --git a/lisp/vc/vc-bzr.el b/lisp/vc/vc-bzr.el
index f6b17d4ce0..7bfb3d0ed3 100644
--- a/lisp/vc/vc-bzr.el
+++ b/lisp/vc/vc-bzr.el
@@ -226,7 +226,7 @@ vc-bzr-state-heuristic
(insert-file-contents dirstate)
(goto-char (point-min))
(if (not (looking-at "#bazaar dirstate flat format 3"))
- (vc-bzr-state file) ; Some other unknown format?
+ (signal 'error "VC: Bzr dirstate is not flat format 3")
(let* ((relfile (file-relative-name file root))
(reldir (file-name-directory relfile)))
(cond
@@ -314,7 +314,9 @@ vc-bzr-state-heuristic
(defun vc-bzr-registered (file)
"Return non-nil if FILE is registered with bzr."
- (let ((state (vc-bzr-state-heuristic file)))
+ (let ((state (condition-case err
+ (vc-bzr-state-heuristic file)
+ (error (signal (car err) (cdr err))))))
(not (memq state '(nil unregistered ignored)))))
(defconst vc-bzr-state-words
@@ -445,45 +447,45 @@ vc-bzr-status
;; (unchanged . WARNING). FIXME unchanged is not the best status to
;; return in case of error.
(with-temp-buffer
- ;; This is with-demoted-errors without the condition-case-unless-debug
- ;; annoyance, which makes it fail during ert testing.
- (condition-case err (vc-bzr-command "status" t 0 file)
- (error (message "Error: %S" err) nil))
(let ((status 'unchanged))
- ;; the only secure status indication in `bzr status' output
- ;; is a couple of lines following the pattern::
- ;; | <status>:
- ;; | <file name>
- ;; if the file is up-to-date, we get no status report from `bzr',
- ;; so if the regexp search for the above pattern fails, we consider
- ;; the file to be up-to-date.
- (goto-char (point-min))
- (when (re-search-forward
- ;; bzr prints paths relative to the repository root.
- (concat "^\\(" vc-bzr-state-words "\\):[ \t\n]+"
- (regexp-quote (vc-bzr-file-name-relative file))
- ;; Bzr appends a '/' to directory names and
- ;; '*' to executable files
- (if (file-directory-p file) "/?" "\\*?")
- "[ \t\n]*$")
- nil t)
- (let ((statusword (match-string 1)))
- ;; Erase the status text that matched.
- (delete-region (match-beginning 0) (match-end 0))
- (setq status
- (intern (string-replace " " "" statusword)))))
- (when status
- (goto-char (point-min))
- (skip-chars-forward " \n\t") ;Throw away spaces.
- (cons status
- ;; "bzr" will output warnings and informational messages to
- ;; stderr; due to Emacs's `vc-do-command' (and, it seems,
- ;; `start-process' itself) limitations, we cannot catch stderr
- ;; and stdout into different buffers. So, if there's anything
- ;; left in the buffer after removing the above status
- ;; keywords, let us just presume that any other message from
- ;; "bzr" is a user warning, and display it.
- (unless (eobp) (buffer-substring (point) (point-max))))))))
+ (condition-case err
+ (progn
+ (vc-bzr-command "status" t 0 file)
+ ;; the only secure status indication in `bzr status' output
+ ;; is a couple of lines following the pattern::
+ ;; | <status>:
+ ;; | <file name>
+ ;; if the file is up-to-date, we get no status report from `bzr',
+ ;; so if the regexp search for the above pattern fails, we consider
+ ;; the file to be up-to-date.
+ (goto-char (point-min))
+ (when (re-search-forward
+ ;; bzr prints paths relative to the repository root.
+ (concat "^\\(" vc-bzr-state-words "\\):[ \t\n]+"
+ (regexp-quote (vc-bzr-file-name-relative file))
+ ;; Bzr appends a '/' to directory names and
+ ;; '*' to executable files
+ (if (file-directory-p file) "/?" "\\*?")
+ "[ \t\n]*$")
+ nil t)
+ (let ((statusword (match-string 1)))
+ ;; Erase the status text that matched.
+ (delete-region (match-beginning 0) (match-end 0))
+ (setq status
+ (intern (string-replace " " "" statusword)))))
+ (when status
+ (goto-char (point-min))
+ (skip-chars-forward " \n\t") ;Throw away spaces.
+ (cons status
+ ;; "bzr" will output warnings and informational messages to
+ ;; stderr; due to Emacs's `vc-do-command' (and, it seems,
+ ;; `start-process' itself) limitations, we cannot catch stderr
+ ;; and stdout into different buffers. So, if there's anything
+ ;; left in the buffer after removing the above status
+ ;; keywords, let us just presume that any other message from
+ ;; "bzr" is a user warning, and display it.
+ (unless (eobp) (buffer-substring (point) (point-max))))))
+ (error (signal (car err) (cdr err)))))))
(defun vc-bzr-state (file)
(let ((result (vc-bzr-status file)))
diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index e2a490092b..778d1139fc 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -359,7 +359,17 @@ vc-do-command
(let ((inhibit-message vc-inhibit-message))
(message "Running in foreground: %s" full-command)))
(let ((buffer-undo-list t))
- (setq status (apply #'process-file command nil t nil squeezed)))
+ (condition-case err
+ (setq status (apply #'process-file command nil t nil squeezed))
+ (error
+ (pcase (car err)
+ ('file-missing
+ (if (string= (cadr err) "Searching for program")
+ ;; The most probable is the lack of the backend binary.
+ (signal 'vc-not-supported (cdr err))
+ (signal (car err) (cdr err))))
+ (_
+ (signal (car err) (cdr err)))))))
(when (and (not (eq t okstatus))
(or (not (integerp status))
(and okstatus (< okstatus status))))
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index 46a486a46c..dda00a8089 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -259,15 +259,18 @@ vc-git-registered
;; path specs.
;; See also: https://marc.info/?l=git&m=125787684318129&w=2
(name (file-relative-name file dir))
- (str (with-demoted-errors "Error: %S"
- (cd dir)
- (vc-git--out-ok "ls-files" "-c" "-z" "--" name)
- ;; If result is empty, use ls-tree to check for deleted
- ;; file.
- (when (eq (point-min) (point-max))
- (vc-git--out-ok "ls-tree" "--name-only" "-z" "HEAD"
- "--" name))
- (buffer-string))))
+ (str (condition-case err
+ (progn
+ (cd dir)
+ (vc-git-command (current-buffer) nil
+ name "ls-files" "-c" "-z" "--")
+ ;; If result is empty, use ls-tree to check for deleted
+ ;; file.
+ (when (eq (point-min) (point-max))
+ (vc-git-command (current-buffer) nil
+ name "ls-tree" "--name-only" "-z" "HEAD" "--"))
+ (buffer-string))
+ (error (signal (car err) (cdr err))))))
(and str
(> (length str) (length name))
(string= (substring str 0 (1+ (length name)))
@@ -1775,7 +1778,8 @@ vc-git-command
"A wrapper around `vc-do-command' for use in vc-git.el.
The difference to vc-do-command is that this function always invokes
`vc-git-program'."
- (let ((coding-system-for-read
+ (let ((inhibit-null-byte-detection t)
+ (coding-system-for-read
(or coding-system-for-read vc-git-log-output-coding-system))
(coding-system-for-write
(or coding-system-for-write vc-git-commits-coding-system))
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index f4a44df3c2..713f0abd19 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -206,7 +206,7 @@ vc-hg-update-on-retrieve-tag
(defun vc-hg-registered (file)
"Return non-nil if FILE is registered with hg."
(when (vc-hg-root file) ; short cut
- (let ((state (vc-state file 'Hg))) ; expensive
+ (let ((state (vc-hg-state file)))
(if (memq state '(ignored unregistered nil))
;; Clear the cache for proper fallback to another backend.
(ignore (vc-file-setprop file 'vc-state nil))
@@ -228,23 +228,22 @@ vc-hg-state-slow
(with-current-buffer
standard-output
(setq status
- (condition-case nil
- ;; Ignore all errors.
+ (condition-case err
(let ((process-environment
;; Avoid localization of messages so we
;; can parse the output. Disable pager.
(append
(list "TERM=dumb" "LANGUAGE=C" "HGPLAIN=1")
process-environment)))
- (process-file
- vc-hg-program nil t nil
+ (vc-hg-command (current-buffer) nil
+ (file-relative-name file)
"--config" "ui.report_untrusted=0"
"--config" "alias.status=status"
"--config" "defaults.status="
- "status" "-A" (file-relative-name file)))
+ "status" "-A"))
;; Some problem happened. E.g. We can't find an `hg'
;; executable.
- (error nil)))))))
+ (error (signal (car err) (cdr err)))))))))
(when (and (eq 0 status)
(> (length out) 0)
(null (string-match ".*: No such file or directory$" out)))
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 1f0eeb7e18..bd9acfc958 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -791,8 +791,15 @@ vc-refresh-state
(add-hook 'vc-mode-line-hook #'vc-mode-line nil t)
(let (backend)
(cond
- ((setq backend (with-demoted-errors "VC refresh error: %S"
- (vc-backend buffer-file-name)))
+ ((setq backend (condition-case err
+ (vc-backend buffer-file-name)
+ (error
+ (pcase (car err)
+ ('vc-not-supported
+ (message "Warning: %S" err))
+ (_
+ (message "VC refresh error: %S" err)))
+ nil)))
;; Let the backend setup any buffer-local things he needs.
(vc-call-backend backend 'find-file-hook)
;; Compute the state and put it in the mode line.
diff --git a/lisp/vc/vc-svn.el b/lisp/vc/vc-svn.el
index 08b53a7169..7eb529a5d9 100644
--- a/lisp/vc/vc-svn.el
+++ b/lisp/vc/vc-svn.el
@@ -148,15 +148,14 @@ vc-svn-registered
(cd (file-name-directory file))
(let* (process-file-side-effects
(status
- (condition-case nil
- ;; Ignore all errors.
+ (condition-case err
(vc-svn-command t t file "status" "-v")
;; Some problem happened. E.g. We can't find an `svn'
;; executable. We used to only catch `file-error' but when
;; the process is run on a remote host via Tramp, the error
;; is only reported via the exit status which is turned into
;; an `error' by vc-do-command.
- (error nil))))
+ (error (signal (car err) (cdr err))))))
(when (eq 0 status)
(let ((parsed (vc-svn-parse-status file)))
(and parsed (not (memq parsed '(ignored unregistered))))))))))
--
2.36.0
--=-=-=--
Simon Tournier <zimon.toutoune@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#57407; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.