Received: (at 81970) by debbugs.gnu.org; 12 Oct 2026 06:02:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 12 02:02:48 2026
Received: from localhost ([127.0.0.1]:59261 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xG97X-0002E9-PH
for submit <at> debbugs.gnu.org; Mon, 12 Oct 2026 02:02:48 -0400
Received: from sonic306-23.consmr.mail.ne1.yahoo.com ([66.163.189.85]:36658)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xG97T-0002DK-Mc
for 81970 <at> debbugs.gnu.org; Mon, 12 Oct 2026 02:02:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1791784956; bh=c5iZPPEMoadyUAlXmzG8iZAn2UZGwtwWL98E+cFerJQ=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=f1p79h8jBJkgZmyYXjtwAwH7YGmNzOwJTFCpIYkwkP3g5zehSpqoC75CFo0gMbNsuHR6EfgGhTpqp0oe8rlxiqc66S+w2+8y3DlLR4ERcNNwdkp3FxkMUeK98ggB1+5V/EGQFt5L1I5ttiaOtHua806o8E0fFtXbOCx/jU/d1Lg=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1791784956; bh=stLMuYw/kthFhHzDavvIvDvQMmM75+nYzFl9vfWDZyh=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=CFOr/HYoE7AwKrAo0NF2Ho7DZ10YrITpOWiP/p87ErDrUAKxKJi+j7NGCt957TRvP5Xqq1uDDzgAo6LOcu36say6nIa2uRfm22FpdD8tCljNurE2iS0HapjUE0eFj72sGi0/gRBNQP7dA0Z7W2NtNbuOpreajCUqE+iqFOUY2RzltNmOOXKqoZtSg7jiO6QlAmyTTCcgCZ6C2c4vTPJ7X7Aev9LIwBAgtax9zBV76vQCTOXSMOKU0+V7BsBzM7SUWDmp9UEgC6W72LsLOlovvH7aSgllI6q5yxavBmFvwi4YAsyQqXr7lTZcSAw0Zlys5mQWBgwl8DbvwvnbldPahA==
X-YMail-OSG: G4IwS4kVM1lWUkvVCW.yf0_ROt5WRpB0y7MQFYI6YIaJvk_K26rHXLbyyLHEqIV
VGhdpARxcjGuIee0ehzw.co_lHm_9eLZJmYPbaJVIc32IwmQ3O8W451Vzxk6ddYz5nLs.60UQT4o
mxxGDrsZ5hZiVmLSF6ph9YFMHg7We1D3RYpjXZigE3QtaKE14LXWsd5izKtJd_ERYLTJmGoyIpmc
CaXEBTF_Rkm11jNgpF7pNXHj024O6.Q_FMnHjPw24Q7XoN2PdL6Zdmmi6Vulh_rdZULMLLKH7phi
Qs7AZXXEL7obtNY8CZFEE4if9RB1uivUpQppIyitipSuv5HHijnNoC_guVRx9lSPPZO.urJ1EuzQ
iryYgg_munWtN0FoTzrcZwxc96WjInsuH9o6zpMPJg_G68VlXNpxiaDx1jP4kIkLgKTOMEFwqxnD
l2.ugmkH2tbTv0e5fRm9ltDugRAfxghjwv8nEA1OIwCovBq2x3pX5BYHQAKSAn4yI0AlQif5bWxN
LYvwq6TOGU5rS_vZnjqMkK0b12vkeBEd2pYHY5Me9MRiBCx.BnR.y9FjQAYhvgjMt5AZU_8vTySk
8oroqn2Hg4OMoFO5s1L6SCfnGDUagAH3Pk8OqM80egeYEJ.QqtHL5u1OJy4KHEZionkrHEVGa4D.
orZIdyMVHfvHL_J1a0Cpy7MdTGX9QRi6Osg4elZMZOdZnMz5_Wx7twNF1Kk356onsDhS8rgrhhpm
GJEad.pYrdSRN9PpjBI1C6kKCYjAkWrXJc4UPYgmTVMfO3JmleBrQ5iHDZv_bXDClvuzuS1d.63Q
FwxRTJ7aPNLLof4uogVu4QoB7lQAw41sUcmZ7w8F4L9.Y3721jOLYEhfw3gNwegdxDoLCrGmlby0
RmKu54h2ny_fdSxN9MAnAXjG2WssUcRlFVk_8cTzBBYqUr.SknGZTBmz508fYu4tMeC6Ko5Sa8ee
5ILLbd.WH2zGK8Pt3P5v2WW8c.A0QzvCemmH7dcTOlgS1sOtMutYhbhsnwTM99OnAAYPPJnbTWb9
Ht1dLJIOsH12tIlPRzbKZ6USNmsULfLGhKaVYrzcoUoh3lPl5DAfDBh.iUp_o5w9UDaYNn3vF.Vw
T3WcNsvpf6eZM1PeEtSQbYqRgl5_lcbKeuejBO_esPUQuPEWdcHBP7L58_.KO8pf7jdWqZs0dZ8U
nkJbzmY2ycQih72JOeMMsfQ6sWf5tkGlUfxRyP45Rmdvkxx1sKqTzf8V_96OiEIuVloVNkT0Fykz
46WXiSoCsRlV5i7JIBl5eMO1ekUoErKlGFlRwsLl_mtdxMWwPtuonWgFaBT0E_berXNuoz0A8em1
CN5NA8TSgukJQ3sTr5rFP2ofoIP_giK6pqguumRnOOzmgm5wa3OVk8SBvMznJFbgHitzRx8VoLNe
3_AoARk_IzEe9ge4qguISZUDMmUJLODsjzDIk6uy0ngV9Vi7i1kRJFt5xsr0ZsWgipk1Pk7rJJ4x
kPYiAdmtolsT7bDNlKqhSjaG7Ay2Gx1jbaXzuNrbgDiqQ0NET6KJA3KGIv3UOXBgLXCdshAOMDaO
bMbdYrdrTht.ydAyjmmS61PLBq1HShP7lx.rfDlvma288XYYszAs0ICSngM3kzf5JU_TpgE9sc0Y
SMKABFKUTVWtmh96y1r5F3fyyQEGNq1q6QcTdyVFURu2zfz6Qxm7w.CCLcdCfrMSLE_3DL4guKv.
xGYAaf9eFttJyInny7wP51I7bdNEY4jotTzr1C120Lk2IqYKomTSnHFu1Qf3Z2GXp8f.5rJANdX7
Yeb1niD_1mV24NgxZadV7FmELzvvH0fxSQZZMwHTZOT0bJ_40o645jPRYWD_mCANxGyVnZZz4GBA
K6fi.CRG512lgrEgNibtYX2dPB3zlXtdaWSxnYQTpm0g6iSat.L4faaslYd_yTn7cfkgzLr3iz6P
klHpX5NPsJb9ASXM9.XfWAnux45TWEmpdvUGgBGShtrPORfaKiw3VhvGH_hELyeymsSHseDKay8u
q9JDwIBvYuEmR7p1gPM5W9LC.HeDkrdwCmRItMSInTQy1.rMp75AtPsCZtJhQR.3u7MNSD2v1cYG
P2i8IHNVclWTqBd19Ztr6ru5AVIzUh_F5YdjnmI.tXPQv0PtWa4mm81ar5jo_qTStmqhX7LqD9cq
qvmNFWNATy_5V7o93fnLg_S85Hmr6ZY_VB45drIe5X7hEC3q_EyxKcSD.IvUBP_eN8xrHk7yfmZV
SX2fTEvUoJ_5Zq1TPcojuuUYELMGPUrS8czoGHvFMoAq9GkuFHkJvXgzyV9wiVUH.I9Sv.gd6qg-
-
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 7e6050f0-2cd9-45b2-9b4f-e09c8d14a2ca
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic306.consmr.mail.ne1.yahoo.com with HTTP; Mon, 12 Oct 2026 06:02:36 +0000
Date: Mon, 12 Oct 2026 06:01:54 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <60095290.2294282.1791784914561@HIDDEN>
In-Reply-To: <jwvtsmtd2iz.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
<1148247025.642123.1791230562417@HIDDEN>
<jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
<400612322.697142.1791241954903@HIDDEN>
<jwvld8bk09e.fsf-monnier+emacs@HIDDEN>
<630576132.930893.1791304998806@HIDDEN>
<jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN>
<1424475815.1803501.1791590594952@HIDDEN>
<jwvld86be21.fsf-monnier+emacs@HIDDEN>
<287350150.1991225.1791594196220@HIDDEN>
<jwvtsmtd2iz.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_2294281_506474041.1791784914559"
X-Mailer: WebService/1.1.26668 YMailNorrin
Content-Length: 10410
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_2294281_506474041.1791784914559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> Thanks, Jeff.=C2=A0 Now comes the harder part: how to change the docs to=
make
> it more clear.=C2=A0 I feel like talking about the behavior of `peg-run` =
in
> the documentation of `if` would be too weird, so I suggest the
> patch below.
> Would it have helped you?
Yes! Thank you. And if I may make a drive-by suggestion for the manual whil=
eyou're in there, I think that this (37):
(with-peg-rules number-grammar
=C2=A0 (peg-run (peg number)))
was probably meant to be:
(with-peg-rules (number-grammar)
=C2=A0 (peg-run (peg number)))
i.e., the with-peg-rules argument should be a list.
Jeff
On Saturday, October 10, 2026 at 08:23:22 AM PDT, Stefan Monnier <monni=
er@HIDDEN> wrote: =20
=20
>>So, IIUC, your confusion is in the difference between the point-motion
>>of primitives like `if` during the parse and how that (fails to)
>>relate(s) to the overall point-motion of `peg-run`?
> That sounds like a fair description. I thought that `if` and `not` someho=
w
> exempted the userfrom *all* point movement, including that in peg-run's
> error handling. I still feel like themanual suggests that.
Thanks, Jeff.=C2=A0 Now comes the harder part: how to change the docs to ma=
ke
it more clear.=C2=A0 I feel like talking about the behavior of `peg-run` in
the documentation of `if` would be too weird, so I suggest the
patch below.
Would it have helped you?
=3D=3D=3D Stefan
diff --git a/doc/lispref/peg.texi b/doc/lispref/peg.texi
index 0c851f15ade..b6b44eeda90 100644
--- a/doc/lispref/peg.texi
+++ b/doc/lispref/peg.texi
@@ -81,10 +81,15 @@ Parsing Expression Grammars
succeeded or not.=C2=A0 If @var{success-function} is provided, it should b=
e a
function that receives as its only argument an anonymous function that
runs all the actions collected on the stack during parsing.=C2=A0 By defau=
lt
-this anonymous function is simply executed.=C2=A0 If parsing fails, a
-function provided as @var{failure-function} will be called with a list
-of @acronym{PEG} expressions that failed during parsing.=C2=A0 By default
-this list is discarded.
+this anonymous function is simply executed, with point where
+@var{peg-matcher} left it.
+
+If parsing fails, on the other hand, regardless where @var{peg-matcher}
+left point, point is moved to the furthest position the parser managed
+to reach, which is often a good guess of the ``error location''.
+Then the function provided as @var{failure-function} is called with
+a list of @acronym{PEG} expressions that failed during parsing.
+By default this list is discarded.
@end defun
=20
The @var{peg-matcher} passed to @code{peg-run} is produced by a call to
diff --git a/lisp/progmodes/peg.el b/lisp/progmodes/peg.el
index 73029d7a223..787053cc7fb 100644
--- a/lisp/progmodes/peg.el
+++ b/lisp/progmodes/peg.el
@@ -352,8 +352,9 @@ peg
=20
(defun peg-run (peg-matcher &optional failure-function success-function)
=C2=A0 "Parse with PEG-MATCHER at point and run the success/failure functio=
n.
-If a match was found, move to the end of the match and call SUCCESS-FUNCTI=
ON
-with one argument: a function which will perform all the actions collected
+If a match was found, run SUCCESS-FUNCTION with point where PEG-MATCHER
+left it (usually, the end of the parse), calling it with one argument,
+a function which will perform all the actions collected
during the parse and then return the resulting stack (or t if empty).
If no match was found, move to the (rightmost) point of parse failure and =
call
FAILURE-FUNCTION with one argument, which is a list of PEG expressions tha=
t
=20
------=_Part_2294281_506474041.1791784914559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydped5b292fyahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div></div>
<div dir=3D"ltr" data-setdir=3D"false"><div><div dir=3D"ltr">> T=
hanks, Jeff. Now comes the harder part: how to change the docs to mak=
e<br></div><div dir=3D"ltr">> it more clear. I feel like talking a=
bout the behavior of `peg-run` in<br></div><div dir=3D"ltr">> the docume=
ntation of `if` would be too weird, so I suggest the<br></div><div dir=3D"l=
tr">> patch below.<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
> Would it have helped you?</div></div><br></div><div dir=3D"ltr" data-s=
etdir=3D"false">Yes! Thank you. And if I may make a drive-by suggestion for=
the manual while</div><div dir=3D"ltr" data-setdir=3D"false">you're in the=
re, I think that this (37):</div><div dir=3D"ltr" data-setdir=3D"false"><br=
></div><div dir=3D"ltr" data-setdir=3D"false"><div dir=3D"ltr" data-setdir=
=3D"false">(with-peg-rules number-grammar<br> (peg-run (peg number)))=
<br><br>was probably meant to be:<br><br>(with-peg-rules (number-grammar)<b=
r> (peg-run (peg number)))<br><br>i.e., the with-peg-rules argument s=
hould be a list.<br><br></div>Jeff</div><div dir=3D"ltr" data-setdir=3D"fal=
se"><br></div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div><br></d=
iv>
=20
</div><div id=3D"ydpfc08201byahoo_quoted_2329594084" class=3D"ydpfc=
08201byahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Saturday, October 10, 2026 at 08:23:22 AM PDT, S=
tefan Monnier <monnier@HIDDEN> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr">>>So, IIUC, your confusion is i=
n the difference between the point-motion<br></div><div dir=3D"ltr">>>=
;of primitives like `if` during the parse and how that (fails to)<br></div>=
<div dir=3D"ltr">>>relate(s) to the overall point-motion of `peg-run`=
?<br></div><div dir=3D"ltr">> That sounds like a fair description. I tho=
ught that `if` and `not` somehow<br></div><div dir=3D"ltr">> exempted th=
e userfrom *all* point movement, including that in peg-run's<br></div><div =
dir=3D"ltr">> error handling. I still feel like themanual suggests that.=
<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Thanks, Jeff. N=
ow comes the harder part: how to change the docs to make<br></div><div dir=
=3D"ltr">it more clear. I feel like talking about the behavior of `pe=
g-run` in<br></div><div dir=3D"ltr">the documentation of `if` would be too =
weird, so I suggest the<br></div><div dir=3D"ltr">patch below.<br></div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">Would it have helped you?<br></div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=3D=
=3D=3D Stefan<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr">diff --git a/doc/lispref/peg.texi b/doc/lispref/peg.texi=
<br></div><div dir=3D"ltr">index 0c851f15ade..b6b44eeda90 100644<br></div><=
div dir=3D"ltr">--- a/doc/lispref/peg.texi<br></div><div dir=3D"ltr">+++ b/=
doc/lispref/peg.texi<br></div><div dir=3D"ltr">@@ -81,10 +81,15 @@ Parsing =
Expression Grammars<br></div><div dir=3D"ltr"> succeeded or not. If @=
var{success-function} is provided, it should be a<br></div><div dir=3D"ltr"=
> function that receives as its only argument an anonymous function that<br=
></div><div dir=3D"ltr"> runs all the actions collected on the stack during=
parsing. By default<br></div><div dir=3D"ltr">-this anonymous functi=
on is simply executed. If parsing fails, a<br></div><div dir=3D"ltr">=
-function provided as @var{failure-function} will be called with a list<br>=
</div><div dir=3D"ltr">-of @acronym{PEG} expressions that failed during par=
sing. By default<br></div><div dir=3D"ltr">-this list is discarded.<b=
r></div><div dir=3D"ltr">+this anonymous function is simply executed, with =
point where<br></div><div dir=3D"ltr">+@var{peg-matcher} left it.<br></div>=
<div dir=3D"ltr">+<br></div><div dir=3D"ltr">+If parsing fails, on the othe=
r hand, regardless where @var{peg-matcher}<br></div><div dir=3D"ltr">+left =
point, point is moved to the furthest position the parser managed<br></div>=
<div dir=3D"ltr">+to reach, which is often a good guess of the ``error loca=
tion''.<br></div><div dir=3D"ltr">+Then the function provided as @var{failu=
re-function} is called with<br></div><div dir=3D"ltr">+a list of @acronym{P=
EG} expressions that failed during parsing.<br></div><div dir=3D"ltr">+By d=
efault this list is discarded.<br></div><div dir=3D"ltr"> @end defun<br></d=
iv><div dir=3D"ltr"> <br></div><div dir=3D"ltr"> The @var{peg-matcher} pass=
ed to @code{peg-run} is produced by a call to<br></div><div dir=3D"ltr">dif=
f --git a/lisp/progmodes/peg.el b/lisp/progmodes/peg.el<br></div><div dir=
=3D"ltr">index 73029d7a223..787053cc7fb 100644<br></div><div dir=3D"ltr">--=
- a/lisp/progmodes/peg.el<br></div><div dir=3D"ltr">+++ b/lisp/progmodes/pe=
g.el<br></div><div dir=3D"ltr">@@ -352,8 +352,9 @@ peg<br></div><div dir=3D=
"ltr"> <br></div><div dir=3D"ltr"> (defun peg-run (peg-matcher &optiona=
l failure-function success-function)<br></div><div dir=3D"ltr"> "Par=
se with PEG-MATCHER at point and run the success/failure function.<br></div=
><div dir=3D"ltr">-If a match was found, move to the end of the match and c=
all SUCCESS-FUNCTION<br></div><div dir=3D"ltr">-with one argument: a functi=
on which will perform all the actions collected<br></div><div dir=3D"ltr">+=
If a match was found, run SUCCESS-FUNCTION with point where PEG-MATCHER<br>=
</div><div dir=3D"ltr">+left it (usually, the end of the parse), calling it=
with one argument,<br></div><div dir=3D"ltr">+a function which will perfor=
m all the actions collected<br></div><div dir=3D"ltr"> during the parse and=
then return the resulting stack (or t if empty).<br></div><div dir=3D"ltr"=
> If no match was found, move to the (rightmost) point of parse failure and=
call<br></div><div dir=3D"ltr"> FAILURE-FUNCTION with one argument, which =
is a list of PEG expressions that<br></div><div dir=3D"ltr"><br></div></div=
>
</div>
</div></body></html>
------=_Part_2294281_506474041.1791784914559--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 10 Oct 2026 15:23:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 10 11:23:31 2026
Received: from localhost ([127.0.0.1]:45547 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xFYv4-0007Tl-4P
for submit <at> debbugs.gnu.org; Sat, 10 Oct 2026 11:23:31 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51509)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1xFYv1-0007Sw-K4
for 81970 <at> debbugs.gnu.org; Sat, 10 Oct 2026 11:23:28 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B2A3E4408A0;
Sat, 10 Oct 2026 11:23:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1791645800;
bh=j+RmLmJKIEziTsV24NZewCYAe2mWHdUr9zdYX4DeNUo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=MiHb7uMIbKsM6TCJCycJoQkqF7h/8jmfk5cbfgfU9dpL50NHux2Wtx9aMc++wGRmq
HVgH+ilv9H58gd9vQcmxRAy9Zzz7+NrFRUchfcHcxGQwoWzZF3n3IfxzQWU29N9L4z
/RqGAs/EbCYituNVYOJg+UMAbeogwaZTrhWt0iyIaeaTk6/MHb6pkRfOj8ilpqlqkf
viXWjkOdfZzhC7BrYjeYmz9cxHEdGeHXK4kSPC6Kg0qXt1kMOpF8VuQp6xRJXC49of
UdYtejf+RR7iPDfEvVyhWtWEQj+fnBlU0Xkf9EXJPHO6+kb1q9TiSv5pXSg/GI6X/p
X9x8X6p560Hcg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 498434405D2;
Sat, 10 Oct 2026 11:23:20 -0400 (EDT)
Received: from pastel (104-195-232-75.cpe.teksavvy.com [104.195.232.75])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1886B120352;
Sat, 10 Oct 2026 11:23:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Jeff Trull <edaskel@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
In-Reply-To: <287350150.1991225.1791594196220@HIDDEN>
Message-ID: <jwvtsmtd2iz.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
<1148247025.642123.1791230562417@HIDDEN>
<jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
<400612322.697142.1791241954903@HIDDEN>
<jwvld8bk09e.fsf-monnier+emacs@HIDDEN>
<630576132.930893.1791304998806@HIDDEN>
<jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN>
<1424475815.1803501.1791590594952@HIDDEN>
<jwvld86be21.fsf-monnier+emacs@HIDDEN>
<287350150.1991225.1791594196220@HIDDEN>
Date: Sat, 10 Oct 2026 11:23:11 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.151 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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: -3.3 (---)
>>So, IIUC, your confusion is in the difference between the point-motion
>>of primitives like `if` during the parse and how that (fails to)
>>relate(s) to the overall point-motion of `peg-run`?
> That sounds like a fair description. I thought that `if` and `not` somehow
> exempted the userfrom *all* point movement, including that in peg-run's
> error handling. I still feel like themanual suggests that.
Thanks, Jeff. Now comes the harder part: how to change the docs to make
it more clear. I feel like talking about the behavior of `peg-run` in
the documentation of `if` would be too weird, so I suggest the
patch below.
Would it have helped you?
=== Stefan
diff --git a/doc/lispref/peg.texi b/doc/lispref/peg.texi
index 0c851f15ade..b6b44eeda90 100644
--- a/doc/lispref/peg.texi
+++ b/doc/lispref/peg.texi
@@ -81,10 +81,15 @@ Parsing Expression Grammars
succeeded or not. If @var{success-function} is provided, it should be a
function that receives as its only argument an anonymous function that
runs all the actions collected on the stack during parsing. By default
-this anonymous function is simply executed. If parsing fails, a
-function provided as @var{failure-function} will be called with a list
-of @acronym{PEG} expressions that failed during parsing. By default
-this list is discarded.
+this anonymous function is simply executed, with point where
+@var{peg-matcher} left it.
+
+If parsing fails, on the other hand, regardless where @var{peg-matcher}
+left point, point is moved to the furthest position the parser managed
+to reach, which is often a good guess of the ``error location''.
+Then the function provided as @var{failure-function} is called with
+a list of @acronym{PEG} expressions that failed during parsing.
+By default this list is discarded.
@end defun
The @var{peg-matcher} passed to @code{peg-run} is produced by a call to
diff --git a/lisp/progmodes/peg.el b/lisp/progmodes/peg.el
index 73029d7a223..787053cc7fb 100644
--- a/lisp/progmodes/peg.el
+++ b/lisp/progmodes/peg.el
@@ -352,8 +352,9 @@ peg
(defun peg-run (peg-matcher &optional failure-function success-function)
"Parse with PEG-MATCHER at point and run the success/failure function.
-If a match was found, move to the end of the match and call SUCCESS-FUNCTION
-with one argument: a function which will perform all the actions collected
+If a match was found, run SUCCESS-FUNCTION with point where PEG-MATCHER
+left it (usually, the end of the parse), calling it with one argument,
+a function which will perform all the actions collected
during the parse and then return the resulting stack (or t if empty).
If no match was found, move to the (rightmost) point of parse failure and call
FAILURE-FUNCTION with one argument, which is a list of PEG expressions that
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 10 Oct 2026 01:03:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 09 21:03:45 2026
Received: from localhost ([127.0.0.1]:57232 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xFLV2-0005q8-Ie
for submit <at> debbugs.gnu.org; Fri, 09 Oct 2026 21:03:45 -0400
Received: from sonic302-23.consmr.mail.ne1.yahoo.com ([66.163.186.149]:36756)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from <edaskel@HIDDEN>) id 1xFLUz-0005pO-OD
for 81970 <at> debbugs.gnu.org; Fri, 09 Oct 2026 21:03:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1791594214; bh=0nyPslqOnVV8OZG+1Du/KNQ1kW1QpPQBY9JANX34NEQ=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=g8LVcjQDz3TD5roGLx1L8BtoC+uVzx4VgdDsbFKdMFPFG+IrAAMUiikOY4NStW4fy8A63YmsyfM3IQZwFdD2P8A6DkPbtWY054JdifT0yYwYYhVn0O8HseXHqNMD22DNsHt5HDybw8YX3rYxoKLsugzgdIak2EVHk9ZeYS9iAX4=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1791594214; bh=KZbbM0szb4EB0ZlIioJQczqw9MQEBylPb2yQqbbA0xE=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=pqWjN/r67gmpBGFOoTst3t4/ztbu/Fq4d9pDpFmXPeF6ZpzwonqouNNa5zE/lZV7dwiLwt1QfJdslbePiVOwz4KDlx1iGZThHalNm0TICCtLOBgKl2tr8lrLK7jcE19eKMALBZRgz9YEkk9h02jy07Xdk+1BPBJf1wbPCMZm4EwljxwYrBsZvxf4AkqWOBtG6DFxPayhsp//haoJmw5aj3pBVgjhGfwL1CNzRDgucTvFo4VGW0dv6ZXB2Xm4SDyi6CRaogHO2qHlcT/TdHxYNrlTq4eQpZ+mSQaTxbd8ntyRSs8xVmicNx/Q9rqnJLfSt2ilcuOvUdngc00cCl8Rug==
X-YMail-OSG: 7cvDb.IVM1m9CIj1f6V2RDdzCnM_lK5Mpi4gOCxtrVqWMVpp7CpLFJW8Yu5L6ZS
t0MVolzPz9hGoYNgrAyn7rZiTbVgM0Uz.Yj1EDELUG9qmq1hSt0drC1b0TIdYDAyqzXUHoGAa5ck
DXni.nXi5focUMSIUm1cgn8HiyH7RFZcHH2e3ecucBUX7vBahNjfviFxTAEZ130A9J7pWx9ZIBSu
LEIdTmyL6b4E4.HYa.jSPB7QFRk5rtsVPyBXdKwdiC3nLUqH1k953ek1d2OuEV6p.QZ9f6u8VPLa
N1ntsgbIoydMljAS5yRdeA26FMucZvWibaZJB11BPg_2DAcKRJwgnGEzzOk2Yx5gFMO.kHweOTbY
bbQNjeV.UnMJCx3zLctIuT38by1k.4qnTaTJdKGotE8JAgUxuClgGMrXW2WmNn899ez1EcRNFstW
noWFtS23cByt6zrvly6ZO6gV9yvkpL124J370FV7s5E2xFL4scGgMq0GGW_rg8Z4GtF.pAb0QHFY
SOl_DpnfLn4FyiwWy9w3zbMjMUxLnV4un9YhbrDdq.gtbbIIf6ATx2s0_nPGvnYwkdvZFHLMjHmS
1KKKYRolToK9BVojDpZDUQvzkocSWn7DAw2iQMD9UeSLgGJqNuwvSU.GuyBAd2LfPN5MxiRxvveI
z8Bd0BkXNBX9KproSZJkXmDtfVfX91cUWTh6ApfUIg3F9VjQSJPJqkviRrdqhu_cElOvH5wyNa2z
OmLIzDpLELzjHVuGKywbdnRLIq1.gw0w6jYP8jioZ9xCbK__CFhN6DeCaKXgwSn28ToXWspAxuT7
8NNji50gENOd5ahR6MsROfEdjrEzk9iLx5Yg9pRnLFPSlc01OYUYuoX9eG5WTr8QXRPAfn6CEeOq
gxxmfhq9j.eZVPRDfoRrjNII77g2pAN_iRlO7PUlCIyB_wX5bVz5V1apiJUbIAcxQp0f0luy852S
tVaSFhoDKd.vvqd2wJbsXku0dyKijiXQrAz2GB_zeiqeE82VrYx7.uzuebtCoKh281jc6mfmPQtK
qSJb2xd46Y_234LcSzmo7fRTnrkvMZjErNrtcLF4pp82IEldUuS7o4m3qX1nTjCn7Kx.djmvm0E5
sLwNgqkqNRQ2lgTEAB9w94MDT4k3lbueLcB7g1UGwI.ik6tL8Zm43XciMSqHTqT2HJDWyr5pYpyC
vScA6qqJdCw86WEkvkI.rAAeST7srFbLAdxM.E9a6Z83dmBBJCrBd51ql3z96RHzjWYLMdukDVJm
CrIrkk5kgRDg6tRj3RcqIcZKUa.7htdGAXG1rdecaoeuDTSSwPGEAD9X.4UBv6knV3k.KEATBgvh
BkQi5aLcBpyTGiHFNSE_QBWpNfRVMyB4JD1KUH_5F3F4_MLHqISBfTisLu2GMP0GbloTJLsmAYmY
ugIat4ts8KBxcHqjFdh_LQRV.ZiZjlQO.Jx8jakqzuSQ95L.ihAuqmUe5OOjcHMFl01DtZ4NVBvh
I_0DzpKjIx.9FtmwN2KhLJKUuq0XP72qvOCR.KRoGG0R9sYV7ubQlmmwERNYhyKtcAZ15TPEIcxj
vlPsVCsl.w7wNb8r6JMp_u6jtBr8gSpmMgMXmAM3b6b4BNwrch.uzHQgqqEaDY5AR2r8lzbbZvMg
e03Y5jU3xErNas4X0cTv37ME4.8Ep._80RB792aeo12465iYO6QqgZOAumR8ofk__r568yjNrvHR
S9TaLasoV_aaLXdXAzZZ31uE_n3xumaMGLxV7wJYfakMHavZ..CG1lJVo5McQ8aJ_yM66lLg0co1
B37BpeMzG.B23dNAZ6UH6gn9NKvayJASWQsc.r._yQ3XsVDq6KqBp0yAUh_PLxwlquW5kh7z4tsi
Utdv3kz.MxvBh91JBu.ZZfGwWHUbGOLvnM81GGBHFS1Bsp_Pbl4ZWEhxERzS0XjT8IImrIgX5iqC
tUR5MCe4Jn3jHqtdwsOMEd2cET_BphuuyCK4seU3pChWCDBo.RanW5mWk_t25XamHrBhRHuP2LoX
.bQyyKzCrdGM_wsxKa3tJ.kqmynxWXBYGX23YkFVko_WzxFIbbObk0grChon4cZBDn6iGUHBBLAg
7r4cl_NJwZQse90FJ18bxQwEy0enuHmgRTdpg_yjB1GznEGCqanUs_COWQgUFKzpDGTASOk5Tujc
8RqrEX6j9cqNSFavjEGtTFwTr5rc5HxUJ2cDvZ11BAPEUembT.F3oN5DRJedFFtwNTPOHdIAy6V5
5KZLyzPe1kb2Mg_F97yifS2XM68Wu3yjixMtCPBJdaOsIGUfMGn.ArQxgALFY0MIxM8YYfbUr2kk
-
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 2a362782-e9a6-4539-a57c-7153dff0eb0d
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sat, 10 Oct 2026 01:03:34 +0000
Date: Sat, 10 Oct 2026 01:03:16 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <287350150.1991225.1791594196220@HIDDEN>
In-Reply-To: <jwvld86be21.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
<1148247025.642123.1791230562417@HIDDEN>
<jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
<400612322.697142.1791241954903@HIDDEN>
<jwvld8bk09e.fsf-monnier+emacs@HIDDEN>
<630576132.930893.1791304998806@HIDDEN>
<jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN>
<1424475815.1803501.1791590594952@HIDDEN>
<jwvld86be21.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_1991224_1862206977.1791594196219"
X-Mailer: WebService/1.1.26668 YMailNorrin
Content-Length: 5179
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_1991224_1862206977.1791594196219
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> On Friday, October 9, 2026 at 05:29:33 PM PDT, Stefan Monnier <monnier@i=
ro.umontreal.ca> wrote:
>
>So, IIUC, your confusion is in the difference between the point-motion
>of primitives like `if` during the parse and how that (fails to)
>relate(s) to the overall point-motion of `peg-run`?
That sounds like a fair description. I thought that `if` and `not` somehow =
exempted the userfrom *all* point movement, including that in peg-run's err=
or handling. I still feel like themanual suggests that.
>
>The point-motion of `peg-run` when the parsing fails is independent of
>the point motion that happened during the parse, so it's "the same" for
>all parsing operators.
Agreed.
>
>IOW, during the parse, a failure always means that point is not moved, but=
at
>the end of the parse, if the overall parsing failed, `peg-run` will move
>point to its best guess of the place where the parsing failed.
Yes.
>
>> Usage with my original testcase:
>> (with-temp-buffer
>>=C2=A0 =C2=A0 (insert "foobar")
>>=C2=A0 =C2=A0 (goto-char (point-min))
>>=C2=A0 =C2=A0 (peg-looking-at (and "foo" "baz"))=C2=A0 =C2=A0; do not mov=
e point regardless of pass/fail
>>=C2=A0 =C2=A0 (point))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; position 1 (where parse started) despite =
fail
>
>Why not use `save-excursion`?
That's a fair question. My actual situation is more complicated, and=C2=A0t=
his made fora clear testcase. But maybe I will end up just using save-excur=
sion.
In any event, doing peg-looking-at as an exercise helped me better grasp ho=
w tocontrol point movement via peg expressions.
Jeff
=20
------=_Part_1991224_1862206977.1791594196219
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp1e50227yahoo-style-wrap" style=3D=
"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">=
<div></div>
<div dir=3D"ltr" data-setdir=3D"false"><div>> On Friday, October=
9, 2026 at 05:29:33 PM PDT, Stefan Monnier <monnier@HIDDEN>=
; wrote:<br>></div><div><br>>So, IIUC, your confusion is in the diffe=
rence between the point-motion<br>>of primitives like `if` during the pa=
rse and how that (fails to)<br>>relate(s) to the overall point-motion of=
`peg-run`?</div><div><br></div><div dir=3D"ltr" data-setdir=3D"false">That=
sounds like a fair description. I thought that `if` and `not` somehow exem=
pted the user</div><div dir=3D"ltr" data-setdir=3D"false">from *all* point =
movement, including that in peg-run's error handling. I still feel like the=
</div><div dir=3D"ltr" data-setdir=3D"false">manual suggests that.</div><di=
v dir=3D"ltr" data-setdir=3D"false"><br>><br>>The point-motion of `pe=
g-run` when the parsing fails is independent of<br>>the point motion tha=
t happened during the parse, so it's "the same" for<br>>all parsing oper=
ators.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"lt=
r" data-setdir=3D"false">Agreed.</div><div dir=3D"ltr" data-setdir=3D"false=
"><br>><br>>IOW, during the parse, a failure always means that point =
is not moved, but at<br>>the end of the parse, if the overall parsing fa=
iled, `peg-run` will move<br>>point to its best guess of the place where=
the parsing failed.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div>=
<div dir=3D"ltr" data-setdir=3D"false">Yes.</div><div dir=3D"ltr" data-setd=
ir=3D"false"><br>><br>>> Usage with my original testcase:<br>>&=
gt; (with-temp-buffer<br>>> (insert "foobar")<br>>>=
; (goto-char (point-min))<br>>> (peg-lookin=
g-at (and "foo" "baz")) ; do not move point regardless of pass/=
fail<br>>> (point)) &n=
bsp; =
; position 1 (where parse started=
) despite fail<br>><br>>Why not use `save-excursion`?<br><br></div>Th=
at's a fair question. My actual situation is more complicated, and thi=
s made for</div><div dir=3D"ltr" data-setdir=3D"false">a clear testcase. Bu=
t maybe I will end up just using save-excursion.</div><div dir=3D"ltr" data=
-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">In any e=
vent, doing peg-looking-at as an exercise helped me better grasp how to</di=
v><div dir=3D"ltr" data-setdir=3D"false">control point movement via peg exp=
ressions.</div><div><br></div>
=20
</div><div id=3D"ydpebf7952yahoo_quoted_1685759211" class=3D"ydpebf=
7952yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;"><div><div dir=3D"ltr">Jeff</div><d=
iv dir=3D"ltr"><br></div></div>
</div>
</div></body></html>
------=_Part_1991224_1862206977.1791594196219--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 10 Oct 2026 00:29:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 09 20:29:42 2026 Received: from localhost ([127.0.0.1]:52696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xFKy5-0003BC-Cu for submit <at> debbugs.gnu.org; Fri, 09 Oct 2026 20:29:42 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1xFKy2-0003Ab-3C for 81970 <at> debbugs.gnu.org; Fri, 09 Oct 2026 20:29:39 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5421D1001A6; Fri, 09 Oct 2026 20:29:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1791592169; bh=N0uvzB8q4BoPEuBxfZerdnfusRplTdMCQI0Zhi6U29k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OP3Lt+XTJZWJar+bhyxpBCV6rmElawPTjARnSdwEcEwq7h/ItHHSDUMIjHF4bKKJp DC1qKWmBgn03fyNKgK6pVJ9SYsr9/EQZp8EELYky4VanrOJ7Q+q4dOlQ0mzQi23o0M zN5ChTzyGtXrJmRVFGCpa23FEimXGd3HrPmz/OgaTN14y2QiSY3gfwoIJRob72kiWc k/aEJWrNW9+PKeCjsUmCwHzatt4nQMFAhtuFO4rZPPyFLHfswEO07yKMSMghynd815 IfXZSARVQxKnJke0b25qtjEpQsrECWuPG7ivP0co/Ivial4Qut3vbFo6Lk1S65VAZQ BliDnt0+qw7yQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4042210016C; Fri, 09 Oct 2026 20:29:29 -0400 (EDT) Received: from alfajor (104-195-241-63.cpe.teksavvy.com [104.195.241.63]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 117ED1203CE; Fri, 9 Oct 2026 20:29:29 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <1424475815.1803501.1791590594952@HIDDEN> Message-ID: <jwvld86be21.fsf-monnier+emacs@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN> <1148247025.642123.1791230562417@HIDDEN> <jwvik3feuj9.fsf-monnier+emacs@HIDDEN> <400612322.697142.1791241954903@HIDDEN> <jwvld8bk09e.fsf-monnier+emacs@HIDDEN> <630576132.930893.1791304998806@HIDDEN> <jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN> <1424475815.1803501.1791590594952@HIDDEN> Date: Fri, 09 Oct 2026 20:29:28 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.115 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: "81970 <at> debbugs.gnu.org" <81970 <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: -3.3 (---) >>Hmm... now you lost me: what makes you think that's not the case? > > If parsing e returns nil, (if e) will fail, and peg-run will move point to > the location of the failure,not the point where it started. This is the > normal behavior that surprised me in the specific caseof `if` and what > I thought the manual implied it, along with `not`, would not do. So, IIUC, your confusion is in the difference between the point-motion of primitives like `if` during the parse and how that (fails to) relate(s) to the overall point-motion of `peg-run`? The point-motion of `peg-run` when the parsing fails is independent of the point motion that happened during the parse, so it's "the same" for all parsing operators. IOW, during the parse, a failure always means that point is not moved, but = at the end of the parse, if the overall parsing failed, `peg-run` will move point to its best guess of the place where the parsing failed. > Usage with my original testcase: > (with-temp-buffer > =A0 =A0(insert "foobar") > =A0 =A0(goto-char (point-min)) > =A0 =A0(peg-looking-at (and "foo" "baz"))=A0 =A0; do not move point regar= dless of pass/fail > =A0 =A0(point))=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; position 1 (where parse started) despite = fail Why not use `save-excursion`? =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 10 Oct 2026 00:04:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 09 20:04:57 2026
Received: from localhost ([127.0.0.1]:48978 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xFKa5-00016E-SX
for submit <at> debbugs.gnu.org; Fri, 09 Oct 2026 20:04:56 -0400
Received: from sonic306-25.consmr.mail.ne1.yahoo.com ([66.163.189.87]:46687)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xFKa0-00015S-0p
for 81970 <at> debbugs.gnu.org; Fri, 09 Oct 2026 20:04:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1791590680; bh=GmwmtuLcHPmmvg2O0ykZyTRdRO290mFe7MU5Grd+OEk=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=DNKPorisvfvbvMLjO8Ke8Um92kLZ5cLf/zVO430ebctHmCGZfmEnSR8qBwcaabtk5deSd4y/Oc5qFwVe6bJxA1/MhpiqERkZ6JXSy0j/3BS+ceAQZz1qdJaiS2yU5lZ4irJHKHyz1poULeN3b3Mt9fqDE8Ve3x+zZiyp0qHdVrQ=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1791590680; bh=Ob7terkAqOK4MdvK2IaglWbEw24W9MwWro2RCht/jjc=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=L7eeKk1jGDF5M3pCSAaZq1g7D4E9ZLR42qTsas3ET3hTSdIP6Z3UfqkvZDg5bPKOqu2034l+5Z1hTlnV8w2kcnZ/pvQ+pZ8QATa/C18CRwQRb6aOzyvIMN4R5QFwsnlnheYpoX7qWjNtAzjXlmJZrrqvlxAd5SOlGbKpvfw0PepIzfCJ0vLmnrrp9A7f8Idt1HEzfbiaePTH13elyKecH8qiawx4ZIjIR3+9PHJ31MpXKaPy1mdQFq10kAUrhSCQ1ERaOKCe9RNTfo1VbLiMQwQZBhNJr5HY6xPQ7jK4/Ua/DRWUGobEnjSQsCUDPxbX5n7cD9DByyNehoFUobHz9Q==
X-YMail-OSG: rTtk2dkVM1kz6uo.Sis_.1UgzSC7fbaVoPMSA_FgFQfHgjGCrYjXwKjPVUl0uK1
YPadC1hBMfHZKcaMnsSUy2aQWXa2At5DiQfSk.VcIkIowGcSLVyRM.eUvrnoXlz7suWUvuRM.E6.
s3Gm0TUg02mnibpj4KmDMgCv5tVnbFXJdi4Cc3snFD.xZNNi.lWIocXtEgP_3WElyc68dItbaV9l
o_wpdZIF8KJFfIX2JnhyEuMf3eufw8Eb_mlJZJWeX_jGOYqN0DrTx8.Ai9ofSjTHszdroRFlOGey
YjlYiBba1Zk3DCDg6FedwZK1l.To3F1Kn8pUi7zbDg8Avm9fTKrSet.DuGd0y7ZsGkDoEjnVDXXw
LFh1.fckm9rBP9wB7PpPtKQZxIfnu985Dt3_AfIVHjLj5fLyHw2SQ1SMvZR6XqqOMaI4IYiFVest
Ar1A8fPJt0GeMPx1lMLdf51vqqVs0zCXzX5Stsl7.YoMPZLCWX27WR0pT_drxH.tIdfH1BYuAy6p
Zj7dTYFiHuGF619Lwyz2HgSAEUowjM3FDhyTbYTFSaFCI40hLassFNDkfcxtA8EsKXXyQQy68N0X
a3SuLVbsfv8Jnk8leA3ypWne0w0HjYpgcJS1dMBV97ViARrIQErwdLpLzvyo3qtxmKKV4RweKzB.
Zt.1xteNGFq_iyfyr.G9ZOe027fGFBEa1BWrHQB2kkBeNPLZf1aJo_EuYZBcCQnrTyxqqg0yWyLC
y4vF.2_MsAjRi2kLA2npMAMUFY_cGg.17P5x_FNbUfLa1NUoMsLGpdWJtehQneU5FXvWeaPkwUYq
Cki9_GjTNHcowZEy_knjO3IDtFL2nLtm9zAoKOiy_ZWTFyKPTxHa3hxE32PgtU4lXnJCEp7Ph8DV
HrSOYlFxSh0HsRIdpkARSGWchpP5LN6_UGBG7Oiax5J8pnBPvwo1pqVuVOryEyVx4f4ClSKvJcEd
dP09CM2SYD7Wlgon8F6ITf0EwTNyE8W4sV45s5ijVX4epD5Z9DHK180iwyS6ijQF94Zx1_Ke9jqr
63XQYmA69aXmgLYzHmWsWsdVnm9SRJzB5N.nVEJLI9sjpyzgPmf9W9Zf_aR6NjldHlvL7_HhGgP0
vP2Ad.GPkcggL7JBYhFotp4ixMMLiIADciovd3qZmMKaATBoOyle9SIs4S2KxNrC2flgw11VHfXi
8yAW9AN1g8AX0pU0n5qGKtL_JnHUYGqGZcZPCWUzvlPgzwzTYO5D5aF1Yr.T3gKODGXetMOzRMq2
SAHOd2UCLegxYxgOdZ0Jve.AUfUTYM_xl6kR12FFzHaQl9_TXp0WMqNzSG8Kl.mMQAvSN.WdoKXl
TDhLuZmYL3Ae3JoekAz.AAQm2VdpeTGZ1Kxn89tHB4jP4g._DDWi1Wg5LB2egDEb7b4P4gZJromd
OJylBaB7dWXwHUFFzl8.uUE89ir4hjJIIB_RTw5L63NYYdhiNVkXdnDZl6LWIcpAbdjFxXhAjGOs
wlEIYcvHK5f6Lcc1CM2qYhRig70tjMIn4G6q4gKkUunKBOwRiZRp7ZW0_Y_JQFB0cTOHjO3ZXE1A
TY5viwGu4APUIu1mORjOwlyfRf9K092EjQZyuDEJj9QMnOMJBEh7HtE30rJOQTdbs8ICUarZsPhQ
bZJLjFhoc.fUHLu0xv1mKeGxW.ztx3AJkKE95wpPj8vEhg2zHxoR_8bsEoIiThXjTvsTUGEKvY_G
4RbWx24K538P1z0W4t215WHB_RZLxyu_K.u6b9a7DteNwuZGRAMKGseFHP0xBTw9aUJIuDng9eE9
06JkJAKtLPf4UdrMMYx_FeP_NoC78HfIe.rU37znelIUlkSSbtAeIfW16gIT0Iua3IFlHCsf3tvT
doS3iLQYL8grdzb.54K8KNwOR8VVMGlf6QBAn3UepjpgHwYYQqqXNNWi4_HX5JIxdh51sRQNG3Cc
LoTE8MW0WKkhDGyk4Q_ZVbY.7UyisDXz8_cqVSob8N6SltHI.1R6_s7kkS6c8zHdvwgx5vay8fXm
fOVU6Xbs07NPRgb286PsurjORkPsxkgBxlNmpkkc1TfXR1PdBL6M_qtxw6kxAtGM9MtWrctRqEaH
RoDXpyDUIv_itx4ph4Rli8B2kDsPWpfyLvH2Rt24zmFW8.JvNvCQofs5LO3TDAJgLM9aabv8UP71
rqEsZ_si.6x8m00jfo6w8yTNqIeN8fVAYT39oIl60lEJvt34pEoZMTNUcr7tCXc3YJeSwUHQS0km
lWHnuVkHrO52Sc.6rMQdTF_bBs9aIXR13u6ZfOvU__a1fI4xkwtW0yaruE77f3gM2im3eMTET
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 827a6d9a-12f6-4d79-a7b9-cb7ccc7b7724
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sat, 10 Oct 2026 00:04:40 +0000
Date: Sat, 10 Oct 2026 00:03:14 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <1424475815.1803501.1791590594952@HIDDEN>
In-Reply-To: <jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
<1148247025.642123.1791230562417@HIDDEN>
<jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
<400612322.697142.1791241954903@HIDDEN>
<jwvld8bk09e.fsf-monnier+emacs@HIDDEN>
<630576132.930893.1791304998806@HIDDEN>
<jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_1803500_135479716.1791590594951"
X-Mailer: WebService/1.1.26668 YMailNorrin
Content-Length: 7080
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_1803500_135479716.1791590594951
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>On Wednesday, October 7, 2026 at 11:23:57 AM PDT, Stefan Monnier <monnier@=
iro.umontreal.ca> wrote:
>
>
>>=C2=A0 > On Monday, October 5, 2026 at 07:58:53 PM PDT, Stefan Monnier <m=
onnier@HIDDEN> wrote:
>>>>=C2=A0 >Not really, no: if `if` fails, it does not move point either (t=
hat's
>>>>>case for pretty much all PEG primitives).
>>>> Well... perhaps we can say that `if` conditionally restores point,
>>>No: *all* primitives leave point unchanged when they fail.>And since `if=
`
>>> restores point when it succeeds, it means that `if`>*never* changes poi=
nt.
>> I'm glad you phrased it this way, because this is the exact point it wou=
ld
>> beuseful to clarify in the manual - that `if` is not exempt from the
>> universal rule.The existing phrasing suggests to me that it is:
>> "Returns non-nil if parsing PEX e from point succeeds (point is not move=
d)."
>> I think other readers may reasonably conclude that an `if` expression,
>> alongwith its children, will complete with point where it started,
>> regardless of whethernil was returned
>
>And they'd be right.
>
>> I understand now that it's not the case,
>
>Hmm... now you lost me: what makes you think that's not the case?
If parsing e returns nil, (if e) will fail, and peg-run will move point to =
the location of the failure,not the point where it started. This is the nor=
mal behavior that surprised me in the specific caseof `if` and what I thoug=
ht the manual implied it, along with `not`, would not do. That is what Iund=
erstand now is "not the case" - that `if` and `not` are the same as any oth=
er primitive,and their restoration-of-point property is only for parses tha=
t pass (return t). Those that failget the move-to-farthest-failure behavior=
.
Perhaps I am the only one who had this interpretation. At any rate I have a=
decent solution nowthat restores point regardless of whether a parse succe=
eded; maybe it will help others in myposition:
(defmacro peg-looking-at (pegexp)
=C2=A0 `(car
=C2=A0 =C2=A0 (peg-run (peg (or (and (if ,pegexp) `(-- 't))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 (and (null) `(-- nil)))))))
Usage with my original testcase:
(with-temp-buffer
=C2=A0 =C2=A0(insert "foobar")
=C2=A0 =C2=A0(goto-char (point-min))
=C2=A0 =C2=A0(peg-looking-at (and "foo" "baz"))=C2=A0 =C2=A0; do not move p=
oint regardless of pass/fail
=C2=A0 =C2=A0(point))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; position 1 (where parse started) despite fail
Jeff
=20
------=_Part_1803500_135479716.1791590594951
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"yahoo-style-wrap" style=3D"font-fami=
ly:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div dir=
=3D"ltr" data-setdir=3D"false"><div>>On Wednesday, October 7, 2026 at 11=
:23:57 AM PDT, Stefan Monnier <monnier@HIDDEN> wrote:<br>&g=
t;<br>><br>>> > On Monday, October 5, 2026 at 07:58:53 PM=
PDT, Stefan Monnier <monnier@HIDDEN> wrote:<br>>>>=
;> >Not really, no: if `if` fails, it does not move point eithe=
r (that's<br>>>>>>case for pretty much all PEG primitives).<=
br>>>>> Well... perhaps we can say that `if` conditionally rest=
ores point,<br>>>>No: *all* primitives leave point unchanged when =
they fail.>And since `if`<br>>>> restores point when it succeed=
s, it means that `if`>*never* changes point.<br>>> I'm glad you ph=
rased it this way, because this is the exact point it would<br>>> beu=
seful to clarify in the manual - that `if` is not exempt from the<br>>&g=
t; universal rule.The existing phrasing suggests to me that it is:<br>>&=
gt; "Returns non-nil if parsing PEX e from point succeeds (point is not mov=
ed)."<br>>> I think other readers may reasonably conclude that an `if=
` expression,<br>>> alongwith its children, will complete with point =
where it started,<br>>> regardless of whethernil was returned<br>>=
<br>>And they'd be right.<br>><br>>> I understand now that it's=
not the case,<br>><br>>Hmm... now you lost me: what makes you think =
that's not the case?<br><br></div></div><div id=3D"ydpf6ed945ayahoo_quoted_=
2534864131" class=3D"ydpf6ed945ayahoo_quoted"><div style=3D"font-family:'He=
lvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">=
<div><div dir=3D"ltr" data-setdir=3D"false">If parsing e returns nil, (if e=
) will fail, and peg-run will move point to the location of the failure,</d=
iv><div dir=3D"ltr" data-setdir=3D"false">not the point where it started. T=
his is the normal behavior that surprised me in the specific case</div><div=
dir=3D"ltr" data-setdir=3D"false">of `if` and what I thought the manual im=
plied it, along with `not`, would not do. That is what I</div><div dir=3D"l=
tr" data-setdir=3D"false">understand now is "not the case" - that `if` and =
`not` are the same as any other primitive,</div><div dir=3D"ltr" data-setdi=
r=3D"false">and their restoration-of-point property is only for parses that=
pass (return t). Those that fail</div><div dir=3D"ltr" data-setdir=3D"fals=
e">get the move-to-farthest-failure behavior.</div><div dir=3D"ltr" data-se=
tdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">Perhaps I a=
m the only one who had this interpretation. At any rate I have a decent sol=
ution now</div><div dir=3D"ltr" data-setdir=3D"false">that restores point r=
egardless of whether a parse succeeded; maybe it will help others in my</di=
v><div dir=3D"ltr" data-setdir=3D"false">position:</div><div dir=3D"ltr" da=
ta-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false"><div>(=
defmacro peg-looking-at (pegexp)<br> `(car<br> (peg-run =
(peg (or (and (if ,pegexp) `(-- 't))<br> =
(and (null) `(-- nil)))))))<br><b=
r></div>Usage with my original testcase:</div><div dir=3D"ltr" data-setdir=
=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false"><div dir=3D"ltr=
" data-setdir=3D"false">(with-temp-buffer<br> (insert "foobar")=
<br> (goto-char (point-min))<br> (peg-looking-at (a=
nd "foo" "baz")) ; do not move point regardless of pass/fail<br=
> (point)) &nbs=
p; &n=
bsp; ; position 1 (where parse started) despite fail<b=
r><br></div><div><br></div>Jeff</div><div dir=3D"ltr" data-setdir=3D"false"=
><br></div></div>
</div>
</div></div></body></html>
------=_Part_1803500_135479716.1791590594951--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 7 Oct 2026 18:24:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 07 14:24:14 2026 Received: from localhost ([127.0.0.1]:56141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xEWJG-00031F-1e for submit <at> debbugs.gnu.org; Wed, 07 Oct 2026 14:24:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12818) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1xEWJ7-00030W-Ih for 81970 <at> debbugs.gnu.org; Wed, 07 Oct 2026 14:24:05 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A3AF610008C; Wed, 07 Oct 2026 14:23:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1791397433; bh=8DMqlbRUNe41j3nRbkzQjX3Km/O2yrvERfzFQm36gNo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NYJ0LjPlHnj7JAjIURITSRq9/ADpGBEeKrNDEyOaRu2hxFJdzZoc9oWV+gSoGsOWM ixNTpwLCJafSvi5eu1oJIezdH7IqZWzJHbyDr7sRuTZlYKmntmptTMNnOCkXAnfHD3 vmzL8dq0JswXIXa8+D8D9Z5MqYnvZMkpXnehpPXLlE9mqWyh3jy/yYMYP5dItkdkiO pY+HR5ehLwXcBse41BFo4GKBmsu5FJN5jJxSv9VnOg3j0ZSs0CgTee7+9IUOvXstUG GNEh6o35dC/6Pz9k9inhEvRFqxYAhVYEWAhfCcKHIhlInzSZKtLgWqSlCX7Cb2yulh +6lTRNitf/FPQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 73FD710006D; Wed, 07 Oct 2026 14:23:53 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68E2A120C95; Wed, 7 Oct 2026 14:23:53 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <630576132.930893.1791304998806@HIDDEN> Message-ID: <jwvpkxl2wwr.fsf-monnier+emacs@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN> <1148247025.642123.1791230562417@HIDDEN> <jwvik3feuj9.fsf-monnier+emacs@HIDDEN> <400612322.697142.1791241954903@HIDDEN> <jwvld8bk09e.fsf-monnier+emacs@HIDDEN> <630576132.930893.1791304998806@HIDDEN> Date: Wed, 07 Oct 2026 14:23:53 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.172 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: "81970 <at> debbugs.gnu.org" <81970 <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: -3.3 (---) > > On Monday, October 5, 2026 at 07:58:53 PM PDT, Stefan Monnier <monnier= @iro.umontreal.ca> wrote: >>>=A0 >Not really, no: if `if` fails, it does not move point either (that's >>>>case for pretty much all PEG primitives). >>> Well... perhaps we can say that `if` conditionally restores point, >>No: *all* primitives leave point unchanged when they fail.>And since `if` >> restores point when it succeeds, it means that `if`>*never* changes poin= t. > I'm glad you phrased it this way, because this is the exact point it would > beuseful to clarify in the manual - that `if` is not exempt from the > universal rule.The existing phrasing suggests to me that it is: > "Returns non-nil if parsing PEX e from point succeeds (point is not moved= )." > I think other readers may reasonably conclude that an `if` expression, > alongwith its children, will complete with point where it started, > regardless of whethernil was returned And they'd be right. > I understand now that it's not the case, Hmm... now you lost me: what makes you think that's not the case? =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 6 Oct 2026 02:59:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 05 22:59:17 2026 Received: from localhost ([127.0.0.1]:33135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xDvOY-0005NX-8F for submit <at> debbugs.gnu.org; Mon, 05 Oct 2026 22:59:13 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33224) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1xDvON-0005M4-Tg for 81970 <at> debbugs.gnu.org; Mon, 05 Oct 2026 22:59:04 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3AD4110009B; Mon, 05 Oct 2026 22:58:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1791255530; bh=4CMOPW6yEzI9xj7gHYtuC34mPc9Z4OwO6Oahj9s3VTQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cZwBvXW89oJdNvhsv3Cy7qVCvxwzvUs7SRQmMXD1cjtsfOLtSNfFcONrEH++aNo0M TokW9gaUVaGhzp7zXcwOr6MNq99EQ3JgWWCdmc45nh5HZ2ShECPSx29vP0ASXvLa4C IF28+/t9IZeDHsStzMA160JNV94/4WBL69JBcbDpCFJn/l/J8kQgGMOqazHqfyZQ6s cP5cWf5bxSplRVR9af2/i9oP0p/8uS3o6wKsuixF5Q/gg6ufBueXh+mdTJpCrrXCYA 8MrlNxZiZTZqHWSNTucWd0GwKhL+As21xKXH/+7lZPoIRoTMhWFl08NCVUTW3xxBbu DqhSgA6eCSfUA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1068F100070; Mon, 05 Oct 2026 22:58:50 -0400 (EDT) Received: from pastel (104-195-198-126.cpe.teksavvy.com [104.195.198.126]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6815120406; Mon, 5 Oct 2026 22:58:49 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <400612322.697142.1791241954903@HIDDEN> Message-ID: <jwvld8bk09e.fsf-monnier+emacs@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN> <1148247025.642123.1791230562417@HIDDEN> <jwvik3feuj9.fsf-monnier+emacs@HIDDEN> <400612322.697142.1791241954903@HIDDEN> Date: Mon, 05 Oct 2026 22:58:47 -0400 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-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.113 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: "81970 <at> debbugs.gnu.org" <81970 <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: -3.3 (---) > >Not really, no: if `if` fails, it does not move point either (that's >>case for pretty much all PEG primitives). > Well... perhaps we can say that `if` conditionally restores point, No: *all* primitives leave point unchanged when they fail. And since `if` restores point when it succeeds, it means that `if` *never* changes point. >>When `and` fails it also doesn't move point, so when `(if "foo" "bar")` >>fails, then it behaves exactly like `(and "foo" "bar")`. > That's exactly what I was surprised by, after having carefully read the > manual. To phrase it in terms of the implementation, `if` only restores = point > if it passes. That's because when it fails, there's nothing to "restore". > I expected it to restore point unconditionally, i.e. be > different than `and`. It *is* different from `and` when it succeeds. But it is like `and` (and all others) when it fails, i.e. point is not moved in that case. > Clearly it doesn't, and that's an acceptable choice, > but I wasn't expecting it. I think "Clearly" is debatable here =F0=9F=99=82. =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 5 Oct 2026 23:13:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 05 19:13:15 2026
Received: from localhost ([127.0.0.1]:46031 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xDrrk-0005mr-IL
for submit <at> debbugs.gnu.org; Mon, 05 Oct 2026 19:13:14 -0400
Received: from sonic302-25.consmr.mail.ne1.yahoo.com ([66.163.186.151]:36801)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from <edaskel@HIDDEN>) id 1xDrrW-0005ld-Od
for 81970 <at> debbugs.gnu.org; Mon, 05 Oct 2026 19:13:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1791241963; bh=7yyQ0BlSbC759sopGhgU6VroiqgUdbTY88fguzvRAhc=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=xdX5yY84+K/J8B6z7LCppEYNRIOuRU1HVXGTNZZPeKP1nYsPKlF8EIo2sqcFo8KUGJGTR4XwRs6tVvYrbU+wnMKcORMbY61UaK7HHNFfWq6kk3UoBBCd+XmChvLqeDWXElxFglHNbxidvZUnwB3rH8EM7m+X6OwF0ZhfJsSzlYI=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1791241963; bh=WIVEo3Rvsze+9zg42hHoYAUnCcSptw+cB6ZnCdtIxpB=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=B0ZO1yDrOKl5Hmg/KjaT3b5ep0uFn66YdiuzjseTqAO2f/szAPa8AAn9mcAWsnvMyxpnan06Ht8qYtCTMu22qQtV1Lx3ppBWMXrubbxl8RCtoeLMG1nXurBErjnYA3VP/65GGBHn2e2TjJrRmQ2QOufQPeFHpXcGYr5chP9hZLQGA7gC0cNhMEQxJVIHLeKtLkMA/TTUD/Ui7tHbAI27h4AIEsiStWyoImzbaKBDbaqB0BhZx1mQp130U0cfgsCD9cjA+j6I7i9qWH4jfXhd0tV97k/BJzkTqCkV2bsZodL9/Jv20zAlSUB9J7K9Ga/W3yAphGRhfnS9MJ/yy4BQOw==
X-YMail-OSG: 6.RNUtAVM1nBWmBcFnOdeOjDjZAVJwcscqYf9xYOH2EQUSFeqfI4Ua39qjFHqZK
xd.XX47i3ShOSUZDj.RYAcqhInelemI9HqM0MrF1CjbnGrg9.zD5KhABrfEQQUj6z1by_MK4NqbS
NP8p9iODrSVK0TVgWKxrIM7TMOUliH.oZ4COlZF7mjPM.NE3E0NHCctOA7O7MGdeP6v3Y7b5KBRb
bwI3KPmysXx.18tFFDJ0WfhCccaffq4xDwtvyNQ_1zaS.o0gHTmgBbtKvTMxrKQ6hLEC5kbiI4Ap
cG3uysO8hpXilXWIbn5ZMKLicge0_hqc9qGDI4RKq9s960nwkv19qlueYbQmk46HObtTHrLu8bPo
0Cb4Fzq.Ndx1qLigxIp1TFtQRkRikKezSfvcJMPw1.6v_sEoPgeJ9b2ZWeUX8vqlVS6WV5cIDY3r
6KPM9zE5u6CyxXz9ZhEANtRev8heAxHfuRZWbzqwvlGeoFSpyBrDl2w_aq0r_AwjhiOsEtpnLr.h
rxdYnG40xAWM4gl2D8zZDy.8XJssUg_DxO7o6JilEvyOhdOZlwuimQALNiA51ns2iZwFzg3mFVTr
nuFlMa3dKP6wEo8VBUUEXglHAJ4SUlUJ83SIQHRCOcK8x8n2kwLIo5dsFocp1twTs_6UiTdzsfta
scmeeYGW.QW7LTSXibD9E.Ewv6w9Pa8bVCPHXg6eAXYPWXMXp8.4wO_yXLgEcmVTyJ0LS_2gKhHX
GWo41ZFFVkmPLDq4pAep6fPvxwtNdamexuzqODXU2_9R9GU42ZyA.Gk.8Yz.LWK0GoaqPUpAFtSL
pMOVT86AJ_RRb.ULuDTDa3.ZFsg9wWR1c576XrJPijRmx35257JhVA1epVsAv7i.bzl2jx55GSMR
.9Xphecp2sDgNwn5.QYhTLvX9sVPMTmqbRUTo.GAqP5MuhtAd8OCLCuprsUlEA2X5q1Ny_1E85BI
sbXei2DJLg4DhAbwFG4FeFCLXubQoqMaghOPo.vrpZttfcnuepTJBuysEj9imiiHWhbYfym1uCSu
zSVveLtmzLZL.AkG_PA_wB9MS80QHs8QY0TvrsldtUKFIS7kfWNOq1y2g_Lc0Tc44jnQPBlqOWrR
w9L.BpjUqGi4U2YsArSzbPFdZDiWbqPRkZmtyBpsMwxuB3y_.hFITzY4oXlmDYvuZ7xZ2YJrEB1t
.e5D8CcH3FW3G5RHMa9jk5AuSYAF6PMYsw5lCc70ceDEsmcy8Ugs82AG5N8yPNAiCRuHKfYLI_qs
W6PEsMKQb40rtljkqe0oYFwnIlLJJshHnIV8SkvPXO5J3iDUNORy6AYBxSznPpJ3_RQTWjo11Q3m
2T9PPnNGnDfebUdUK.tnWRyQyUm7sid9SZmyNAXBQA0rGzjJiQDOcVK_.rnpTPZJQLU2sHO57ZOs
Z8XjAfFw5GLEaxghfN1XoevtlvRGyDxvlCBDHKdg2GM0zdfDQsD35DZuFig.DeRAhIU59r7EmRKr
vuY.ZkTy._e1AF1hc3GxMTprUPFEI7x2NBXaj608YJS4gH3z6HWwPzmxBGXfOqg4uJArlItK1rHL
HDbDIaABIsQw46yVWdD77P3qDUkwHVY.tC1ZWj__z6q62pRCSwW2MvQspCPQkES1nA2098mt6Wn1
epDNouAx0jLVj7plx0b3E8aQ44pA4ZHwf22fR7Sotm5rx3L3vzg3X9F4oY7fT3DmJj_JuFKuFsNI
hgEB_zblIaMTpXPezdoMHoFppJkbHQUTbTKAM9UBDSpeaNOdtTBFNnUx9j5NCjpFt3.9ACdYrf.m
4AHJlb.6zqxTR6yLu_Qx7AFfFf6JVSGTZDqsS4SLrKuW8DxkC2G6l8RsM1FN3ZZiD27E3fIZQYlh
BdiFwsqd0m9R8N2GDRHhrgExGjurCYK2Vztojwlb7pObCHabgMnE8ThFmbgpIVYyO3q1IKBOiTzD
dEn2zOA_E9.MhAqMncUYBkN7rq5kdUG93kqAoJaFu_WJt.hCCwUHmhKufTTWmym6zHWIKJ7aRQ1q
fR6cmTT5uVx03Qs1Gdiqmk.DeP9.RaTbq4AJbquAf6z_FIa3V5dcBC_Yj9NwLL2SHeGu3gTDRHeE
mII0fVFTsCNON8nVVwpJF8RBZ1XPN1B7ohXVwIERrGgdd21jBuVNXgCskACpc1D8CTRJbOf8SjVz
NZaYNt.g9rlkGrc0yHlkHjWLVFjfhSE9zTtHJCJ2islaQe.hSsX06JwJjlzl8z1ooFR7Guj7labR
ZNmUOFEMLr2G9vRypnGIfjEO5ljpXtWJbDnuNcT_olm6EIKkZkc5QhxfQFKsWK4BTpcZxGuEZhaK
k4EKF
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 98534ac7-37dd-48f3-8526-7a437dfe521f
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 5 Oct 2026 23:12:43 +0000
Date: Mon, 5 Oct 2026 23:12:34 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <400612322.697142.1791241954903@HIDDEN>
In-Reply-To: <jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
<1148247025.642123.1791230562417@HIDDEN>
<jwvik3feuj9.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_697141_655317935.1791241954901"
X-Mailer: WebService/1.1.26668 YMailNorrin
Content-Length: 11592
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_697141_655317935.1791241954901
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>Not really, no: if `if` fails, it does not move point either (that's
>case for pretty much all PEG primitives).
Well... perhaps we can say that `if` conditionally restores point, and`and`=
does not, since that's the implementation?
But the documentation takes pains to say that `if` and several other primit=
ives"do not move point", so the implied model is:
some primitives move point, and others don't=C2=A0 =C2=A0 =C2=A0 =C2=A0 << =
the manual
vs.
some primitives restore point, and others don't.=C2=A0 =C2=A0 =C2=A0<< the =
code
The former is presumably easier to understand, which is why it's in themanu=
al that way.
>
>>> Hence, my question: what did you expect `(if "foo" "baz")` to do?
>> Fail, and leave point at the beginning of the buffer.
>> Note this is different from what I expected (and "foo" "baz")
>
>When `and` fails it also doesn't move point, so when `(if "foo" "bar")`
>fails, then it behaves exactly like `(and "foo" "bar")`.
That's exactly what I was surprised by, after having carefully read the man=
ual.To phrase it in terms of the implementation, `if` only restores point i=
f it passes.I expected it to restore point unconditionally, i.e. be differe=
nt than `and`.Clearly it doesn't, and that's an acceptable choice, but I wa=
sn't expecting it.
>>=C2=A0
>> > "The if and not operators accept a parsing expression and interpret it
>> > as a boolean,without moving point" sounded to me as though they would
>> > not move point regardless of which boolean value was returned.
>>=C2=A0
>> That's the case.=C2=A0 The point motion you see doesn't come from `if` b=
ut
>> from `peg-run`.
From reading the code, the point motion comes from primitives like `str`, a=
ndpoint restoration (conditionally) comes from primitives like `if`.=C2=A0B=
ut it need not be -and indeed is not - described in the manual this way. In=
stead it speaks of pointmovement by primitives.
I think the manual's choice was a natural one, even if it's not technically=
correct,since it produces a useful model for the user. I only suggest that=
the movementbe clearly noted as dependent on whether the primitive passes =
or fails. Specifically,in "PEX Definitions" change:
(if e)
=C2=A0 =C2=A0 Returns non-nil if parsing PEX e from point succeeds (point i=
s not moved).
to:
=C2=A0 =C2=A0 Returns non-nil and does not move point if parsing PEX e from=
point succeeds
or "and point does not move" if you prefer. Similarly for `not`.
It's consistent with the existing documentation, and it would have reduced =
my confusion.
Thanks,Jeff
On Monday, October 5, 2026 at 01:58:53 PM PDT, Stefan Monnier <monnier@=
iro.umontreal.ca> wrote: =20
=20
>>=C2=A0 =C2=A0 =C2=A0(with-temp-buffer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(insert "foobar")
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(goto-char (point-min))
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(list (peg-run (peg (if "foo") "fooba"))
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(- (point) (point-min))))
>>=C2=A0
>> returns `(t 5)`, which shows that the `if` did not move point.
> Right, because it passes.
Not really, no: if `if` fails, it does not move point either (that's
case for pretty much all PEG primitives).
>> Hence, my question: what did you expect `(if "foo" "baz")` to do?
> Fail, and leave point at the beginning of the buffer.
> Note this is different fromwhat I expected (and "foo" "baz")
When `and` fails it also doesn't move point, so when `(if "foo" "bar")`
fails, then it behaves exactly like `(and "foo" "bar")`.
> "The if and not operators accept a parsing expression andinterpret it
> as a boolean,without moving point" sounded to me as though they would
> not move point regardless of which boolean value wasreturned.
That's the case.=C2=A0 The point motion you see doesn't come from `if` but
from `peg-run`.
=3D=3D=3D Stefan
=20
------=_Part_697141_655317935.1791241954901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydpe96802f8yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div></div>
<div dir=3D"ltr" data-setdir=3D"false"><div>>Not really, no: if =
`if` fails, it does not move point either (that's<br>>case for pretty mu=
ch all PEG primitives).</div><div><br></div><div dir=3D"ltr" data-setdir=3D=
"false">Well... perhaps we can say that `if` conditionally restores point, =
and</div><div dir=3D"ltr" data-setdir=3D"false">`and` does not, since that'=
s the implementation?</div><div dir=3D"ltr" data-setdir=3D"false"><br></div=
><div dir=3D"ltr" data-setdir=3D"false">But the documentation takes pains t=
o say that `if` and several other primitives</div><div dir=3D"ltr" data-set=
dir=3D"false">"do not move point", so the implied model is:</div><div dir=
=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"fa=
lse">some primitives move point, and others don't  =
; << the manual</div><div dir=3D"ltr" data-setdir=3D"false"><br></div=
><div dir=3D"ltr" data-setdir=3D"false">vs.</div><div dir=3D"ltr" data-setd=
ir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">some primitiv=
es restore point, and others don't. << the code</d=
iv><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-s=
etdir=3D"false">The former is presumably easier to understand, which is why=
it's in the</div><div dir=3D"ltr" data-setdir=3D"false">manual that way.</=
div><div dir=3D"ltr" data-setdir=3D"false"><br>><br>>>> Hence, =
my question: what did you expect `(if "foo" "baz")` to do?<br>>> Fail=
, and leave point at the beginning of the buffer.<br>>> Note this is =
different from what I expected (and "foo" "baz")<br>><br>>When `and` =
fails it also doesn't move point, so when `(if "foo" "bar")`<br>>fails, =
then it behaves exactly like `(and "foo" "bar")`.</div><div><br></div><div =
dir=3D"ltr" data-setdir=3D"false">That's exactly what I was surprised by, a=
fter having carefully read the manual.</div><div dir=3D"ltr" data-setdir=3D=
"false">To phrase it in terms of the implementation, `if` only restores poi=
nt if it passes.</div><div dir=3D"ltr" data-setdir=3D"false">I expected it =
to restore point unconditionally, i.e. be different than `and`.</div><div d=
ir=3D"ltr" data-setdir=3D"false">Clearly it doesn't, and that's an acceptab=
le choice, but I wasn't expecting it.</div><div dir=3D"ltr" data-setdir=3D"=
false"><br>>> <br>>> > "The if and not operators accept=
a parsing expression and interpret it<br>>> > as a boolean,withou=
t moving point" sounded to me as though they would<br>>> > not mov=
e point regardless of which boolean value was returned.<br>>> <b=
r>>> That's the case. The point motion you see doesn't come fro=
m `if` but<br>>> from `peg-run`.</div><div dir=3D"ltr" data-setdir=3D=
"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">From reading the c=
ode, the point motion comes from primitives like `str`, and</div><div dir=
=3D"ltr" data-setdir=3D"false">point restoration (conditionally) comes from=
primitives like `if`. But it need not be -</div><div dir=3D"ltr" data=
-setdir=3D"false">and indeed is not - described in the manual this way. Ins=
tead it speaks of point</div><div dir=3D"ltr" data-setdir=3D"false">movemen=
t by primitives.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div=
dir=3D"ltr" data-setdir=3D"false">I think the manual's choice was a natura=
l one, even if it's not technically correct,</div><div dir=3D"ltr" data-set=
dir=3D"false">since it produces a useful model for the user. I only suggest=
that the movement</div><div dir=3D"ltr" data-setdir=3D"false">be clearly n=
oted as dependent on whether the primitive passes or fails. Specifically,</=
div><div dir=3D"ltr" data-setdir=3D"false">in "PEX Definitions" change:</di=
v><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-se=
tdir=3D"false"><div>(if e)<br> Returns non-nil if parsing PEX =
e from point succeeds (point is not moved).<br><br></div>to:</div><div dir=
=3D"ltr" data-setdir=3D"false"><br> Returns non-nil and does n=
ot move point if parsing PEX e from point succeeds</div><div dir=3D"ltr" da=
ta-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">or "an=
d point does not move" if you prefer. Similarly for `not`.</div><div dir=3D=
"ltr" data-setdir=3D"false"><br></div>It's consistent with the existing doc=
umentation, and it would have reduced my confusion.</div><div dir=3D"ltr" d=
ata-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">Thank=
s,</div><div dir=3D"ltr" data-setdir=3D"false">Jeff</div><div dir=3D"ltr" d=
ata-setdir=3D"false"><br></div>
=20
</div><div id=3D"yahoo_quoted_1902273786" class=3D"yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Monday, October 5, 2026 at 01:58:53 PM PDT, Stef=
an Monnier <monnier@HIDDEN> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr">>> (with-tem=
p-buffer<br></div><div dir=3D"ltr">>> (inse=
rt "foobar")<br></div><div dir=3D"ltr">>> (=
goto-char (point-min))<br></div><div dir=3D"ltr">>> &nbs=
p; (list (peg-run (peg (if "foo") "fooba"))<br></div><div dir=3D"ltr"=
>>> (- (point) (point-=
min))))<br></div><div dir=3D"ltr">>> <br></div><div dir=3D"ltr">=
>> returns `(t 5)`, which shows that the `if` did not move point.<br>=
</div><div dir=3D"ltr">> Right, because it passes.<br></div><div dir=3D"=
ltr"><br></div><div dir=3D"ltr">Not really, no: if `if` fails, it does not =
move point either (that's<br></div><div dir=3D"ltr">case for pretty much al=
l PEG primitives).<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">>=
;> Hence, my question: what did you expect `(if "foo" "baz")` to do?<br>=
</div><div dir=3D"ltr">> Fail, and leave point at the beginning of the b=
uffer.<br></div><div dir=3D"ltr">> Note this is different fromwhat I exp=
ected (and "foo" "baz")<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr=
">When `and` fails it also doesn't move point, so when `(if "foo" "bar")`<b=
r></div><div dir=3D"ltr">fails, then it behaves exactly like `(and "foo" "b=
ar")`.<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">> "The if an=
d not operators accept a parsing expression andinterpret it<br></div><div d=
ir=3D"ltr">> as a boolean,without moving point" sounded to me as though =
they would<br></div><div dir=3D"ltr">> not move point regardless of whic=
h boolean value wasreturned.<br></div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">That's the case. The point motion you see doesn't come from =
`if` but<br></div><div dir=3D"ltr">from `peg-run`.<br></div><div dir=3D"ltr=
"><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=3D=3D=3D Stefan<br=
></div><div dir=3D"ltr"><br></div></div>
</div>
</div></body></html>
------=_Part_697141_655317935.1791241954901--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 5 Oct 2026 20:59:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 05 16:59:09 2026 Received: from localhost ([127.0.0.1]:54031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xDpm5-00049t-Rb for submit <at> debbugs.gnu.org; Mon, 05 Oct 2026 16:59:08 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48493) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1xDply-000493-UR for 81970 <at> debbugs.gnu.org; Mon, 05 Oct 2026 16:59:01 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0A1C04423C0; Mon, 05 Oct 2026 16:58:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1791233931; bh=2zyFJFPPWQNaAgmKQT+aC83OeWe2Bc5FlLCi2cm7JuI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PEeRuDEfNne5zLGJHiDc00scStbyubT717VVSgSMb+7c/gaXC2aGeA9e4n3zNxUtK Fkab+chFk7uRTVS/EL7CQpeFVPIMAY0mfrIYCHRgMWEKH47E5OPXW4onWAVfHl6QFn 3j/fESZTG/5ls3Ubxofoo0BORABa9TfpUaqlkr/rfzhZ4pQjQvqt37cHL1whIg28M1 SUYQ3dP2oRhayyLuBc9rmQYSPngLj+Qr8D8H21PPcAmNm3riZjD7vgyNUOJo8f13fJ GpNqe8xSjaFO0b2HXwxQ7dkbTs9nkRBVx0soLtH5YkXQwhDM+eUb0dyG2zvnyLemKm QaPpbesMTRrHw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EDABD442398; Mon, 05 Oct 2026 16:58:50 -0400 (EDT) Received: from alfajor (unknown [10.34.230.255]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D910A120234; Mon, 5 Oct 2026 16:58:50 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <1148247025.642123.1791230562417@HIDDEN> Message-ID: <jwvik3feuj9.fsf-monnier+emacs@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN> <1148247025.642123.1791230562417@HIDDEN> Date: Mon, 05 Oct 2026 16:58:49 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: "81970 <at> debbugs.gnu.org" <81970 <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: -3.3 (---) >>=A0 =A0 =A0(with-temp-buffer >>=A0 =A0 =A0 =A0(insert "foobar") >>=A0 =A0 =A0 =A0(goto-char (point-min)) >>=A0 =A0 =A0 =A0(list (peg-run (peg (if "foo") "fooba")) >>=A0 =A0 =A0 =A0 =A0 =A0 =A0(- (point) (point-min)))) >>=A0 >> returns `(t 5)`, which shows that the `if` did not move point. > Right, because it passes. Not really, no: if `if` fails, it does not move point either (that's case for pretty much all PEG primitives). >> Hence, my question: what did you expect `(if "foo" "baz")` to do? > Fail, and leave point at the beginning of the buffer. > Note this is different fromwhat I expected (and "foo" "baz") When `and` fails it also doesn't move point, so when `(if "foo" "bar")` fails, then it behaves exactly like `(and "foo" "bar")`. > "The if and not operators accept a parsing expression andinterpret it > as a boolean,without moving point" sounded to me as though they would > not move point regardless of which boolean value wasreturned. That's the case. The point motion you see doesn't come from `if` but from `peg-run`. =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 5 Oct 2026 20:04:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 05 16:04:05 2026
Received: from localhost ([127.0.0.1]:44134 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xDoug-0008BV-Vk
for submit <at> debbugs.gnu.org; Mon, 05 Oct 2026 16:04:05 -0400
Received: from sonic302-25.consmr.mail.ne1.yahoo.com ([66.163.186.151]:34416)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from <edaskel@HIDDEN>) id 1xDouT-0008AH-31
for 81970 <at> debbugs.gnu.org; Mon, 05 Oct 2026 16:03:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1791230613; bh=mCKy8qv23FrJfmzV3sezuLL5UxkbuizwqJ1gRXXFq20=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=z9eNs/dhhVeDtmXc6PIMDixp6gj+NZhbaMFU7TXh8U99VZeMwVztZG6TcQyGgyXhjt2iuXs4QThOFvSRByVE6w2QA6yLmgoawISjlAm3j7Gobh+AJ5YwJZsHQl0zTpgDzM1/nqx54RXaA5LmrQhyi/lY8P+ORAkAcxfED+5kqM4=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1791230613; bh=17HaTMbPI2fr7Gdn3n/Fb4bXFMt17WM54zhHxHcGzvP=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=fPfPElrnqro0IPstkvVE6Sq1PrPY67MoEoqPqjV+X1MR/lnQMF5Vgivi7S/l5GKDjiAV5pJzar6/toLRxCcb5KbeQiO86P4b0icdWRa79FbJOY7vGy4vTyuUpo5uNOyw6X+ujX3rUVI+fTUCLaXSxn4a5Mya34BtyCIqRdtdN3bfGpSuYNaL63ROHxCFEgAUNjTlVafJ0j1xwkd8kD+KG0hCKSIJHzDUfKw8lu9FCADO7RPHzzlPLxepaxo/Ttirwjkhei8kkViP6f5Jykj4cDZVHuKkUyzvSQ4gseJ0PpXoD7J47RV+9wR3lRMuYsgAYOX3eo8LPvkv2eachGYtBQ==
X-YMail-OSG: RXxtM8sVM1liXRFwPzoJ8sQcFtnreADnpEfKurKKpDYWFlyrU987sX9QrdozYIL
D0SnYCCQhN7SzOY7TfH5iYatUfwDOCTkffq.jlkCNPGZvdGZiU0cIazbVdNp.ubTEaemvFVDa4US
8UNry3kMNzqnHeXPB0xAG4OTpENBJe3Vtbk286QyQ77I02j7rD.9eNmCyzuo51uKfJglzEfJ9zGW
TWyq7VHORhwTWs.SpklD5w.2cfrmY2JId3w4LA5E1zSa0teY.vILB9RIVuAZO43qbsQQR0RJ6WEy
Ji96BGMGdgrFH3yjW5yxUyJV5Kyle.Yy721UQVnvhn_TsbMKeBh9al0mrTiRyQ._KNp_67J.LpZL
FS8SvaPra95ZnXzB2me9ynKFdDSoTF9HseDKtpoYnTFST3kdvxlrHYhy8gnPZjbow8qDCsXIYP55
kT8_Rx5HHgRbnGl6RWfRbt8vNXkytPc824IvVcaZUsiaj.7KbrCJ.cWNDQSCZQif8rWXE9ZzuDpz
OMpazNAzgr3maKDSVz1189qaammpcni5orydd_XqR4Zjg05p_A0p9AhFIwjcl2rWCA4IOLNi3tB_
DNiIBA1LJ3bvtoSRb74ooueNaHTH3Tkte7Z2m.rLx5V2psq7.fipOBBOYWq2WnyAYFSg32ntzE1W
mngjDo46t2Ka5NssVAwIUhKscNo.e2enngUUJARQ2xlMY2ifYPjclBBmOKnZ6GXwn5GO0Kc.HSTk
JkCDVKVYLcU51EVgLKH7uKHUlXlQosibNNGZLOjzJsVEqlnwNom7sxNCuiE9FVPwBx6gAKev3rPc
zbD9KSzyXkQIWCp92sXDMekL6rIreUijsfr1ak1T1BbqcKIgLvFbVelQkpVMztbD0iadNviMOavH
9UQ5YFXmFuraBx5_cjxEl5v0zUWPyxh00jt7AxbJXGpYdQ.oAUOD9X60btM9T4QC_yQvj_d.o4lm
Xj24_ANReLKbKyZRSDzDbPkuzlGUaOMU1jEb2sae9hfbEh0UCJWWdAI52f1_EoG_Y4w6BZxWNnMt
t3QojgZtNd7MdKHjrEDQ8uT1QeuUllTuOwyaaQbbuG9rd3bQGC26gvgIjphPxwZPMAANjT2mkYXV
V1CzgQLheimmdPJGCBZaazgGXgH0tDsVwzJrl1Y4daFvEcWQv5rvipnb9GU.AY__msvTqjOjgWBU
tJPAen9Ouu5LLvKxwwW0FIcvwbS3WhXowEgmsFEfy9gU4JVA9g4CXjentQjffV1meV6qIeJkhhvb
s84qLdvAbDbUFAz8AhbA4vxZ2ZYw_dHUWeHETbqCzVd6M1c.eGYk1quxoDpCNjNce3.pqI.gp1c_
DRLRgWwaWZXHTY7dDcKu8E.oQ3I6vjzDvn8ZK7GZuYFduylMEoqeSSjESSMSp_R4MkUYCA4v.xvi
zGm9OmQxFyyMDTrn6riovndH.8tY5r_yRMH_zHR7Q0fesDhDB_Qlzg1L5pck43Vk6QIHyaPehidp
5JmbiEgHjeKE747_DCaiMZ93UHD3rb6PeDKIVTo.NCjLnOx9QZ6rKCORsOrhPFc6wOArAEaZ5r2O
KNqpJ.0VJcCn_pF8qyRmbX5t.y.bPYn2RunmGesD3mQsyldfnx4OUZRmHb5ikxs4mcjhVyYTYzzz
XUhrGbRKPIKL1VPs7KWnh8IebEvaemakigWN8rX6VsmwLgka1B.oQDyP2qZr1fT6PPwqKM_IsS_S
jsnlRensDBowy32DOOoRfkb0It5YAxQg47IoRRZlfGVBkC7RU7OujoxeHpDCt9xKF98JgRZo1uKw
iyrYAtRqDWdlEPRnlX16E9nd8ky7QAZ1DhoYdygF7M_RtxodMvnX9hubv3kNFHDA1WqPgCp9h2uK
5UaDY0pUbwpkiU0GG633yw5F5r.HaEHCtEf6h7Ow7EWgcyR8Tzj7fXtnUnGqWZWE7ryr2P6WmvTJ
hMbjfeaInhXNNewTSYZ2ph5FV477kRkcVghELOrBThMYJU8SwTlkV8HrXDk2Yo5eMa7Dq1Mk.xXG
TZyT0CMVhMX8ac2J0HUR0q78.J1s6vuuZ9_EjESlNAaaLO.NtztZj5lZ8Vl0Qynzv8HtOCRtNohS
9XKLMbMc4M1VYHV54zmizdVVvPB_holG9L0JHqko8E4muWEqH9UCsz4Dfu33szrbO2q37habyoIm
iZrLUwGMmyGwxs08YB8v0m0fov1yJqmpVbA6MKN75UV9ymnzh8m3fdMLChuHhaKKqAUA5Uo_Hiok
iNU16Y2bKkuxjcAC3B9iq8jOmH03Kr6qKREe7Ve5X1j6ryuyMb2joXX7V8uutGIbG1f4j4ZTY
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 3f0f1d2a-fd09-46d6-9278-b4a32e40f0a3
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 5 Oct 2026 20:03:33 +0000
Date: Mon, 5 Oct 2026 20:02:42 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <1148247025.642123.1791230562417@HIDDEN>
In-Reply-To: <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_642122_923080716.1791230562415"
X-Mailer: WebService/1.1.26668 YMailNorrin
Content-Length: 13617
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_642122_923080716.1791230562415
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Stefan! I was hoping you would chime in.
This is my second time using peg.el in a project and I've found it very use=
ful.Clearly my understanding of it is incomplete. I'll describe briefly my =
originalinterpretation of the docs, and then answer your specific questions=
.
Basically, I assumed that in the PEX Definitions page, everything described=
after
"The following expressions are used as anchors or tests =E2=80=93 they *do =
notmove point*,but return a boolean value which can be used to constrainmat=
ches as a way ofcontrolling the parsing process" [emphasis mine].
This is reemphasized in the descriptions of "if" and "not" ("point is not m=
oved").
In my application this was a useful property, so I wrote some code with "if=
" and"not" assuming that in *all* circumstances, pass or fail, point would =
be in an expectedplace. Root-causing that resulted in this bug report.
On Monday, October 5, 2026 at 11:49:58 AM EDT, Stefan Monnier <monnier@i=
ro.umontreal.ca> wrote: =20
=20
> > Returns non-nil if parsing PEX e from point succeeds (point is not mo=
ved)
> > In fact, point may sometimes be moved. Consider this code:
> >
> > (with-temp-buffer
> >=C2=A0 (insert "foobar")
> >=C2=A0 (beginning-of-buffer)
> >=C2=A0 (peg-run (peg (if "foo" "baz")))
> >=C2=A0 (point))
>=C2=A0
> What do you expect this to do?
What I formerly expected it to do is: fail, and not move point. I still kin=
d of preferthat, but I can see that's not how it was intended.
> Notice that `(if "foo" "bar")` here should behave pretty much like
> `(if "foobar")`
>=C2=A0
> > The position 4 (immediately following "foo") is returned.
>=C2=A0
The position 4 is returned by with-temp-buffer, not peg-run. I apologize fo=
r theambiguity. The point (hah!) was for the testcase to show that point ha=
d moved,which I thought was erroneous. I imagined readers would evaluate th=
e fullexpression in e.g. a Lisp buffer.
> As explained by Helmut, this is not the case: nil is returned because
> the parse fails, and point is moved to right after "foo" because that's
> our best guess as to where the parsing failed.
That is consistent with the other expressions and I can see that's what was=
intended, now.
>=C2=A0
> Notice also that
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0(with-temp-buffer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(insert "foobar")
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(goto-char (point-min))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(list (peg-run (peg (if "foo") "fooba"))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(- (point) (point-min))))
>=C2=A0
> returns `(t 5)`, which shows that the `if` did not move point.
Right, because it passes. I was assuming that was also true when it fails.I=
thought that "if" and "not" were special in this way, compared to other co=
nstructs.
> So I think the problem here is one of misunderstanding.
For sure.
>=C2=A0
> Hence, my question: what did you expect `(if "foo" "baz")` to do?
Fail, and leave point at the beginning of the buffer. Note this is differen=
t fromwhat I expected
(and "foo" "baz")
to do, which is to fail and leave point after "foo" - as it does.
> Bonus points if you can help us find which part of the doc lead
> you to this misunderstanding.
It's hard to say, given that this confusion is in my own head, and others m=
ay read the docsdifferently. But I think that in the PEX Definitions page, =
the bit about:
"they do notmove point, but return a boolean value which can be used to con=
strainmatches"
and in Writing PEG Rules:
"The if and not operators accept a parsing expression andinterpret it as a =
boolean,without moving point"
sounded to me as though they would not move point regardless of which boole=
an value wasreturned. I understand now that this is only the case for a non=
-nil return value.=C2=A0 I'm not sureif there is a way to express this bett=
er, but maybe de-emphasizing (or qualifying) thenot-moving-point bits would=
help.
I think this bug can be either closed as user error, or turned into a docum=
entation issue ifyou think that's warranted. Thanks for your help.
Best,Jeff
=20
------=_Part_642122_923080716.1791230562415
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp5d9fcc15yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;" dir=3D"ltr" data-setdir=3D"false"><div></div>
<div dir=3D"ltr" data-setdir=3D"false">Hi Stefan! I was hoping you =
would chime in.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div =
dir=3D"ltr" data-setdir=3D"false">This is my second time using peg.el in a =
project and I've found it very useful.</div><div dir=3D"ltr" data-setdir=3D=
"false">Clearly my understanding of it is incomplete. I'll describe briefly=
my original</div><div dir=3D"ltr" data-setdir=3D"false">interpretation of =
the docs, and then answer your specific questions.</div><div dir=3D"ltr" da=
ta-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">Basica=
lly, I assumed that in the PEX Definitions page, everything described after=
</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" dat=
a-setdir=3D"false">"<span>The following expressions are used as anchors or =
tests =E2=80=93 they *do not
move point*,</span></div><div dir=3D"ltr" data-setdir=3D"false"><span>but r=
eturn a boolean value which can be used to constrain
matches as a way of</span></div><div dir=3D"ltr" data-setdir=3D"false"><spa=
n>controlling the parsing process" [emphasis mine].</span></div><div dir=3D=
"ltr" data-setdir=3D"false"><span><br></span></div><div dir=3D"ltr" data-se=
tdir=3D"false"><span>This is reemphasized in the descriptions of "if" and "=
not" ("point is not moved").</span></div><div dir=3D"ltr" data-setdir=3D"fa=
lse"><span><br></span></div>In my application this was a useful property, s=
o I wrote some code with "if" and</div><div class=3D"ydp5d9fcc15yahoo-style=
-wrap" style=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;fo=
nt-size:13px;" dir=3D"ltr" data-setdir=3D"false">"not" assuming that in *al=
l* circumstances, pass or fail, point would be in an expected</div><div cla=
ss=3D"ydp5d9fcc15yahoo-style-wrap" style=3D"font-family:Helvetica Neue, Hel=
vetica, Arial, sans-serif;font-size:13px;" dir=3D"ltr" data-setdir=3D"false=
">place. Root-causing that resulted in this bug report.</div><div class=3D"=
ydp5d9fcc15yahoo-style-wrap" style=3D"font-family:Helvetica Neue, Helvetica=
, Arial, sans-serif;font-size:13px;" dir=3D"ltr" data-setdir=3D"false"><br>=
</div><div class=3D"ydp5d9fcc15yahoo-style-wrap" style=3D"font-family:Helve=
tica Neue, Helvetica, Arial, sans-serif;font-size:13px;" dir=3D"ltr" data-s=
etdir=3D"false"><br></div><div class=3D"ydp5d9fcc15yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;" dir=3D"ltr" data-setdir=3D"false"><br></div><div id=3D"ydp61144ea2yahoo_=
quoted_1457898800" class=3D"ydp61144ea2yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Monday, October 5, 2026 at 11:49:58 AM EDT, Stef=
an Monnier <monnier@HIDDEN> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div dir=3D"ltr" data-setdir=3D"false"> <div>> > Retu=
rns non-nil if parsing PEX e from point succeeds (point is not moved)<br>&g=
t; > In fact, point may sometimes be moved. Consider this code:<br>> =
><br>> > (with-temp-buffer<br>> > (insert "foobar")<br=
>> > (beginning-of-buffer)<br>> > (peg-run (peg (if=
"foo" "baz")))<br>> > (point))<br>> <br>> What do y=
ou expect this to do?</div><div><br></div><div dir=3D"ltr" data-setdir=3D"f=
alse">What I formerly expected it to do is: fail, and not move point. I sti=
ll kind of prefer</div><div dir=3D"ltr" data-setdir=3D"false">that, but I c=
an see that's not how it was intended.</div><div dir=3D"ltr" data-setdir=3D=
"false"><br>> Notice that `(if "foo" "bar")` here should behave pretty m=
uch like<br>> `(if "foobar")`<br>> <br>> > The position 4 =
(immediately following "foo") is returned.<br>> </div><div dir=3D"l=
tr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">=
The position 4 is returned by with-temp-buffer, not peg-run. I apologize fo=
r the</div><div dir=3D"ltr" data-setdir=3D"false">ambiguity. The point (hah=
!) was for the testcase to show that point had moved,</div><div dir=3D"ltr"=
data-setdir=3D"false">which I thought was erroneous. I imagined readers wo=
uld evaluate the full</div><div dir=3D"ltr" data-setdir=3D"false">expressio=
n in e.g. a Lisp buffer.</div><div dir=3D"ltr" data-setdir=3D"false"><br>&g=
t; As explained by Helmut, this is not the case: nil is returned because<br=
>> the parse fails, and point is moved to right after "foo" because that=
's<br>> our best guess as to where the parsing failed.</div><div dir=3D"=
ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false"=
>That is consistent with the other expressions and I can see that's what wa=
s intended, now.<br>> <br>> Notice also that<br>> <br>&g=
t; (with-temp-buffer<br>> (=
insert "foobar")<br>> (goto-char (point-min))<=
br>> (list (peg-run (peg (if "foo") "fooba"))<=
br>> (- (point) (point-mi=
n))))<br>> <br>> returns `(t 5)`, which shows that the `if` did =
not move point.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div =
dir=3D"ltr" data-setdir=3D"false">Right, because it passes. I was assuming =
that was also true when it fails.</div><div dir=3D"ltr" data-setdir=3D"fals=
e">I thought that "if" and "not" were special in this way, compared to othe=
r constructs.</div><div dir=3D"ltr" data-setdir=3D"false"><br>> So I thi=
nk the problem here is one of misunderstanding.</div><div dir=3D"ltr" data-=
setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">For sure.=
</div><div dir=3D"ltr" data-setdir=3D"false"><br>> <br>> Hence, =
my question: what did you expect `(if "foo" "baz")` to do?</div><div dir=3D=
"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false=
">Fail, and leave point at the beginning of the buffer. Note this is differ=
ent from</div><div dir=3D"ltr" data-setdir=3D"false">what I expected</div><=
div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdi=
r=3D"false">(and "foo" "baz")</div><div dir=3D"ltr" data-setdir=3D"false"><=
br></div><div dir=3D"ltr" data-setdir=3D"false">to do, which is to fail and=
leave point after "foo" - as it does.</div><div dir=3D"ltr" data-setdir=3D=
"false"><br>> Bonus points if you can help us find which part of the doc=
lead<br>> you to this misunderstanding.</div><div dir=3D"ltr" data-setd=
ir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">It's hard to =
say, given that this confusion is in my own head, and others may read the d=
ocs</div><div dir=3D"ltr" data-setdir=3D"false">differently. But I think th=
at in the PEX Definitions page, the bit about:</div><div dir=3D"ltr" data-s=
etdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">"<span>the=
y do not
move point, but return a boolean value which can be used to constrain
matches"</span></div><div dir=3D"ltr" data-setdir=3D"false"><span><br></spa=
n></div><div dir=3D"ltr" data-setdir=3D"false"><span>and in Writing PEG Rul=
es:</span></div><div dir=3D"ltr" data-setdir=3D"false"><span><br></span></d=
iv><div dir=3D"ltr" data-setdir=3D"false"><span>"<span>The <code class=3D"y=
dp6f60898dcode">if</code> and <code class=3D"ydp6f60898dcode">not</code> op=
erators accept a parsing expression and
interpret it as a boolean,</span></span></div><div dir=3D"ltr" data-setdir=
=3D"false"><span><span>without moving point</span>"</span></div><div dir=3D=
"ltr" data-setdir=3D"false"><span><br></span></div><div dir=3D"ltr" data-se=
tdir=3D"false">sounded to me as though they would not move point regardless=
of which boolean value was</div><div dir=3D"ltr" data-setdir=3D"false">ret=
urned. I understand now that this is only the case for a non-nil return val=
ue. I'm not sure</div><div dir=3D"ltr" data-setdir=3D"false">if there=
is a way to express this better, but maybe de-emphasizing (or qualifying) =
the</div><div dir=3D"ltr" data-setdir=3D"false">not-moving-point bits would=
help.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"lt=
r" data-setdir=3D"false">I think this bug can be either closed as user erro=
r, or turned into a documentation issue if</div><div dir=3D"ltr" data-setdi=
r=3D"false">you think that's warranted. Thanks for your help.</div><div dir=
=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"fa=
lse">Best,</div><div dir=3D"ltr" data-setdir=3D"false">Jeff</div><div dir=
=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"fa=
lse"><br></div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D=
"ltr"><br></div></div>
</div>
</div></body></html>
------=_Part_642122_923080716.1791230562415--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 5 Oct 2026 15:50:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 05 11:50:04 2026
Received: from localhost ([127.0.0.1]:53708 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xDkx1-0003N0-Nk
for submit <at> debbugs.gnu.org; Mon, 05 Oct 2026 11:50:04 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30377)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1xDkwz-0003M4-02
for 81970 <at> debbugs.gnu.org; Mon, 05 Oct 2026 11:50:01 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1FAB1441992;
Mon, 05 Oct 2026 11:49:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1791215394;
bh=+q9EQjeYKixUWEYKvHZgJSXmoqaqnq4zWQCnXjreGFc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=bkiDTddy239jlV4uWS3w5ocapgW+PHUEOXuLUXWvqaLSycfRP5g5E+WF9z3jI8M9Z
/8aVCr4DCRwS4Y4BJIDVbG4y4o8trAILFjrADhB9+5cpaXO5j7tFAQkDrj41WY7mnr
/KnJ6o9Lm/27JKzZ4gq+eM6NAFi3X/tGz9wmZgKPylbZefvW+Kz0bwo96j5VDdYDJq
WR2VohPiY1crZx3izFX7gFjBNSD2y2QHujEsOqWlAOq8sJPMzYzCbHFid4fz05ob+i
7e6wm/IOjbtYEcJ/NcqgczSTA/3tl6EsbJPMaNXIk/AlODNcK6dWUgYz9bApgF1QTC
c3M+njNmNbg7Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1430C441A4B;
Mon, 05 Oct 2026 11:49:54 -0400 (EDT)
Received: from alfajor (modemcable181.99-80-70.mc.videotron.ca [70.80.99.181])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA50A1203CE;
Mon, 5 Oct 2026 11:49:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Jeff Trull <edaskel@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
In-Reply-To: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
Message-ID: <jwvik3gf9b8.fsf-monnier+emacs@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
Date: Mon, 05 Oct 2026 11:49:53 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.148 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81970
Cc: 81970 <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: -3.3 (---)
> Returns non-nil if parsing PEX e from point succeeds (point is not moved)
> In fact, point may sometimes be moved. Consider this code:
>
> (with-temp-buffer
> (insert "foobar")
> (beginning-of-buffer)
> (peg-run (peg (if "foo" "baz")))
> (point))
What do you expect this to do?
Notice that `(if "foo" "bar")` here should behave pretty much like
`(if "foobar")`
> The position 4 (immediately following "foo") is returned.
As explained by Helmut, this is not the case: nil is returned because
the parse fails, and point is moved to right after "foo" because that's
our best guess as to where the parsing failed.
Notice also that
(with-temp-buffer
(insert "foobar")
(goto-char (point-min))
(list (peg-run (peg (if "foo") "fooba"))
(- (point) (point-min))))
returns `(t 5)`, which shows that the `if` did not move point.
So I think the problem here is one of misunderstanding.
Hence, my question: what did you expect `(if "foo" "baz")` to do?
Bonus points if you can help us find which part of the doc lead
you to this misunderstanding.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 3 Oct 2026 08:14:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 03 04:14:45 2026 Received: from localhost ([127.0.0.1]:46404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCutD-0003kr-6A for submit <at> debbugs.gnu.org; Sat, 03 Oct 2026 04:14:42 -0400 Received: from mail-wr2-x10.google.com ([2a00:1450:4864:30::10]:47599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1xCut6-0003kK-Ei for 81970 <at> debbugs.gnu.org; Sat, 03 Oct 2026 04:14:35 -0400 Received: by mail-wr2-x10.google.com with SMTP id ffacd0b85a97d-4834977ae75so76218f8f.3 for <81970 <at> debbugs.gnu.org>; Sat, 03 Oct 2026 01:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791015266; x=1791620066; darn=debbugs.gnu.org; h=content-transfer-encoding:content-type:mime-version:user-agent :message-id:date:references:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=EqvuJ83GD8lCfEAacgrxU8QcxyNFesND78queVnhMvU=; b=XKcpK98GiPbLdpFad8GPkCE4m4268V0t5NNvA6VpKV54Vl4pxWFwfF9xJFT14GfdeP pCxoV+inkBjyjSyG2D2bmwHBT101UH0Sd63IXCGc0rqThBz21L0J1eo5Cfx0nqo/bvJ0 xOxOGsadWdz6nj2gNkQvCq4PGUSsCPlx/kdljTXiCdhdbFRlheRLDU2MmwFygiBF0Fs4 9cYi89h2C8b1snV3GULrjXzIghBwSHc2oR7+d9SzJzboHCr2M12F3nqIHPc+so+3JkgA 1P/qz0ptLPuACWudUtK0LQ4QfrMTPiwOPDSS8e44cxRJBVhedQWeJfXzFN5U3+gyoyjk Py4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791015266; x=1791620066; h=content-transfer-encoding:content-type:mime-version:user-agent :message-id:date:references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EqvuJ83GD8lCfEAacgrxU8QcxyNFesND78queVnhMvU=; b=rlHxfc7A9eyYV3DfGcxvK/o6enRxHXUCuolzOpKe/FC7VvALH24XKpRM2GrW0jTR6Y TeSpUPBWE5Lccr8tTGIKGoVAR+B1I4pO/ipqgQh/cx2wGtKw7yo6f32KTo1SP8pGkYw4 2cnlbWCEQ04X/MpDW2YayG+1zXVlBUlszGbUGbQmMoRaDtZl+7OjSy13q3/0p0vzCnbx YzNgFBVRHOgPkQzsraDDltF3yYcBLa6l8KB84/N/EMCtNltzfGHCJLj7M7GHECDzKb7u zYpFtfEWSdnDKp13f9DG9zGsrmMXSdJXJ7u0IANWQiJqIqEihzv4T1zoS1YChu7iwE/S p/og== X-Gm-Message-State: AFq9FYLsqi7MTF6OEv4Q1Aq0PGlAHnr4IXdpzLlxY/5LtrBv1Fll03MQ 0C1iTKO+olP4J8efFvfiQ2ajR609NBgY++73GEY8RHh7bVLhxNOhwPkEptgP+w== X-Gm-Gg: AYBFou1hr7TMbO6CI6njf3s2a9CjINpgCWarhByWJcmIS6qCNcWu8w6HyDHrgcydTPK rec3tUKWzYgq7GAaP+6famGZwD66YpBQ40k5/jb59hxLoLxFXfVKS6pzIKe/3F5Z0R7XqXuEgaL khZHS4IPZAuhfY/WgWV65dl0LLF/RlI5ooZWfcX7CDJRaeGGFzYY7dLjg+qAA7UnkDOtjz+dJ5o 4iuA0cUp6Qfp+q0k1sm1vhqHjWpmSvI1TJOB2l4iXOqxxrrpV0yvXd4deEwOZCXPphmgR5x6WpV 42KU73Nf8TBVglnNG1qJGYoUajhjgdHrDpj3g0UnoJJqcRVh12XghoQAGWpJ7R0BihYPaVnPxnh lk8JDyMgqI2gTF98ffYEMk1VulySEN0y/oge4wyyVebLyK5vPc/6okte3X4c3u0mQ7ejYw3yoAi 2VaZTUuCvp0/V6yWkTsAv7Slzkdt7ZF+hIHivSNiPaX+tqgm5NnM3dCCKdJG2742SHh0Vr8lumC AcKvbxAYw37LefBhNWGFfd8XaX0 X-Received: by 2002:a05:6000:981:b0:487:40a:5ba8 with SMTP id ffacd0b85a97d-48b12739890mr8831760f8f.15.1791015265878; Sat, 03 Oct 2026 01:14:25 -0700 (PDT) Received: from hessra (dial-189137.pool.broadband44.net. [212.46.189.137]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b382f9bc0sm10964561f8f.41.2026.10.03.01.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Oct 2026 01:14:25 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <CAF_DUeH4dSeH60B9qtT2ETYJW12qCk3fz5VO5VPwRfifDVTbyw@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <87bj9c8450.fsf@HIDDEN> <CAF_DUeFczpGNNga=Up-NVydy6DhATt3JxTJMfqC4xQUZB3rTZA@HIDDEN> <CAF_DUeH4dSeH60B9qtT2ETYJW12qCk3fz5VO5VPwRfifDVTbyw@HIDDEN> Date: Sat, 03 Oct 2026 10:14:24 +0200 Message-ID: <8733un8alb.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: 1.0 (+) X-Debbugs-Envelope-To: 81970 Cc: 81970 <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: 0.0 (/) On Fri, Oct 02 2026, Jeff Trull wrote: > On Fri, Oct 2, 2026, 5:18=E2=80=AFPM Jeff Trull <edaskel@HIDDEN> wrote: > > On Fri, Oct 2, 2026, 12:21=E2=80=AFPM Helmut Eller <eller.helmut@HIDDEN= om> > wrote: > > On Thu, Oct 01 2026, Jeff Trull via "Bug reports for GNU Emacs, the > Swiss army knife of text editors" wrote: > > > In PEG, an "if" expression is defined in the Elisp manual as: > > > > Returns non-nil if parsing PEX e from point succeeds (point is not > moved) > > > > In fact, point may sometimes be moved. Consider this code: > > > > (with-temp-buffer > > (insert "foobar") > > (beginning-of-buffer) > > (peg-run (peg (if "foo" "baz"))) > > (point)) > > > > The position 4 (immediately following "foo") is returned. > > Note that in this example peg-run returns nil. That means that the > part > of the documentation that you quoted does not apply. > > If a match fails (as in the example), peg-run leaves point where the > parse failed. > > In other words: the example works as intended. > > Helmut > > Can you check again? In my session (31.1) peg-run returns 4 (the > position following the partial match), not nil. > > Apologies yes, peg-run returns nil in this case. But point is left at 4, = the > position following the partial match. peg-run is behaving properly - "if"= is > not. I don't know how to explain why "if" is correct other than repeat myself. The docstring of peg-run says: If no match was found, move to the (rightmost) point of parse failure and call FAILURE-FUNCTION with one argument, which is a list of PEG expressions that failed at this point. Helmut
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 21:22:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 17:22:35 2026 Received: from localhost ([127.0.0.1]:41593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCkiB-0007S0-AJ for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 17:22:35 -0400 Received: from sonic314-24.consmr.mail.ne1.yahoo.com ([66.163.189.150]:40884) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xCki8-0007Rf-OB for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 17:22:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1790976146; bh=FqRbqxiJJV6VyylEHKXAEcIY2gxqYQUxkbv/AjEkmZs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From:Subject:Reply-To; b=lKwoTTJrgZG443luS9bx2Zv+TCQsmShPS/cBWAEx0F8h3X/HGA4o3BeiBch0QQC9k4c57QKQSWIte2mrtJ6OvtwTLtrs+OlxNHVU8L0zGpK3U6G31nAvK4Z3sZ1vIaHYu943YVP1uaiTv0oA+EFXfSwjK9vs+6SBo7TPv25ADy0= X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1790976146; bh=+IoSaDwgVOxX8/1+dW08gUp5LP4k7RNartuhGrl7mbH=; h=X-Sonic-MF:From:Date:Subject:To:From:Subject; b=NyCbRwkiFZ8AA5DIbejoz2BniarN6xcE40xVW+SmZHDwqpRkG4dYqVrxOr7sPQe1OgvxSIzgbeozeakghv5MQgZMskTg7myRe9cGUnoSr1LW7gCUexTC4boQXxeWqHOqMfH9XrelYWv3FSsY5emhm+pGSwbZCRnfvBGI/IUt8uWqIf2ZgmMtWrDDno+isexUTkDi8r3MCteFspPbRbVl3auMOLiC7j2Hm9H7BMGXOsx31BS3gXKhki1JDu12xpdC/gOVtahsRDP/RLet2iFV1GLIkTX/yxF0D0bcTKS65PW0E8uny94l3dn6bq9JvQpMnSx8w6yLPj0OhHXXIDjHtA== X-YMail-OSG: vkWDxsIVM1kSrKgn7a1651aQo7Ow9jNjzdbGR3E126TT0Y765Sm7GzsaddnRQ5h 1etXdUD6kubUTLX9Aiw6rW3i2kTfFE45OH3XqO6rRfkaBwkhYbt3y5FX2S8VFHTXWNkiYCwp1n2j u4ILKpvQ3o0JHmjHoAbmpUspdTNBZlVBv8nCYTQlxQmbZrtI3u.GBua5HJlNuginfflIV9WMPM0l R_AfxQSbcxtvjBAyhdGFfSc7pE3aUtP0BynAlF4gHWUKL6WSUeHevwyBkC0LylErEAO2UJy18jcM w8IqRfo9eYvWjAaTg28eAe5VDWZp8d8pZ1_FVzUp6Z8fKHg7JZMS.w6YBd60rBtu_3ED7Qla0nLu koOnBynV0f2XW7JcI0BrF3uqbCL3nhE9DSxwJhC3TUmbvdSuuKBr5S57959rMYzief545mYgP.UI IlylbkKpsbEVAp4FVD6Xo2qDMpdF9K7mx4_GKXuKn1BKDRmuKPYhMqTwC4hXfpERbSH.NYsU17bJ mEnicEp4q3uG7K_oa1OSyWb9P0dYlrfLpevZI6gmV1oSYHLlqu3xbOKDystLZptTkSnw85UMIvR3 CB_qTEufb1Win.8RUe5k.R7Nm9LJfqkA2qqaI5QV1b2BzD08pIhoq4hjUPoxjWUH4QdJiabOrBod B0gbWaGb_IuaBIjKJmUs8U2WuAZokho0Q6WeOvBlHjKkTNN8qAa1bjalXWknI4bdpEy40TJge2hf LZyS0euIEY9QwC2D2yAZFaVQs2EU049DkbHFjlmpD48vMDfhYEIbd1IdzSAwgTFxgxRLl1SVkR.p P2JwbjytUU64MSnMZV9YOGsFsdRFESYphcR.CGNxhaKR3enfWhctvYMBFD4_j1lzUOe10cz6GBAc bW8Nj2fjVwoCZU5pF7e0FaOdmJE.3fNq1gQbG_iQVN7aOB4SgGdyGhdyEsDyCHpGRVtZuX..Er7E HrJpeWJ7lDMTYKdMkmM75AMYvCXQk2FlF7Y4zIjZv4vtAAvr70qYHRlyxWzk9aoF1fqPAyWyNmM0 D0695szRnborwMFiNZ2dq6Qm4Syp0dsIZhM5nFMkpDHN19pJZE7NttvZmbVNc4ZmgF_hlXChZuuj ffn2LTYcJAAA2ED1ZfptPzYe6T3BAJsnynZsAaLWz63ngjta3s1ty_56E9byqDC1ZlZMXp77b3Lm hua0PXH51_kCwnoE2pzRTnMwGttCG9FQ.wdWzxrpTq9JQQz3_0sNTv3LyhWhl2Tgg8Bbn9e1mRLm iVTsbpmNC2SbtIfxgVeYswmwf1vxdO1r1oUMSanJGBE88DYNVjg1o0d7B1K5B2EQOlmQeZ14.NJ7 Nb81lvowOHMUxyW0MVCETwrN62BIpWBRGaeXxBOQO.nqdni_pr.ipmXqZICeL0PheBfrHduNqCqS .klrASX2zx5VBi4I2BE84nVQntRRciD0IComKMKBVMfHwdAbx2kuJYritYyTXkzNdQXZj_pySDyA qkTwwxwywdGxUzV_JMTZdFWwCd6QOnj7Dt6vzG41UUJzQtKuVp4URli92O4c9ZSoHY2UGh2YHQZp eSETNhXv.aKxZz6sfNbq2f_Tc3FHBMnhEcaM0Z_S2YEkzia5vCbUq1g7r1XKP9V4DaUga20UiW9q i0tmfoOg.3.DcYqoc3jgMfEThs6xHLFlif2rbJErfUyCW1oxDUddozQr5W_s4cB7qDihIQwVBacn b.o49ESbsLXcnNJ1dfuC9PKo.QbN_J7kfrEomPH5ANhy1h54C2vxyi3HSDwHzu_ptrO2rvkHdvkF 6P_AJ6sEjHBmPPpq3Cvp79aNo0pucvsPjdEXSQHDgX5dZ.LxesWc1.96NxAHVYmkgSvlZvrv6huW sgHFSAQWrHl5satnB8W_sOavEcO1mJD8I3zMfBO60gjAM4lqHdo48G0OQ7bmMHTZEo63LHBkia6m 6qsZLjPlnp3VIW5xGzlfcU7JfRaE5M3gqK2Ab5dKPZennrf7wBc7v7l2H4qq0A3q0xGti7.0ZP09 cxTJOnDBcI6ZzNXwLDftqJRJW_fx26kITKufqe3WT8Zp4cKKkRkmhVWJpnXjOFjrq1zbfliwgitt 8w.yjfz5w11FPPqCf4.U3z2B4yam.IKRTFZDqxAZN4c.2ZI.Lh2MgKtOvz25E9ZTlxN_VlCzvMh8 _Z.Z5Y10MhBvjAOSfesjtawg9jVnYbFcm3QZcS_1sSI_FTr9ErHpTaY5.f10wYwSkwn3r62IoiU6 aJxIZO6LQM5S83HKnu9D4REmBZETWfC5shs3Zx1GDsuqjSfYfF8DQIzkzuWbVqOrRqeF53_O_qFC MWoQ- X-Sonic-MF: <edaskel@HIDDEN> X-Sonic-ID: 85bbff5c-926d-4489-ab7d-b43ae37c4c9c Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 2 Oct 2026 21:22:26 +0000 Received: by hermes--production-bf1-6d6877594b-7khjh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 02da19eea20783523587ad02fde2c596; Fri, 02 Oct 2026 21:22:22 +0000 (UTC) Received: by mail-yx2-f43.google.com with SMTP id 00721157ae682-895353e9051so103267b3.0 for <81970 <at> debbugs.gnu.org>; Fri, 02 Oct 2026 14:22:22 -0700 (PDT) X-Gm-Message-State: AFq9FYLXnWP/Hc7cNyDXJth7+a/lgUYR+JNBbc4aMXj2fTQzcLaEC5WT XptezOckql5F1H268ro57uMd0Rg1pDFwDkQ+gZR+/hlwVfIbstZKcZJEdhXYen2IWUEaiUDiSL/ 6v2Naa2eleik+ZOR/RcyNMKu3WFV1bZQ= X-Received: by 2002:a05:690c:c50f:b0:8a8:4931:6198 with SMTP id 00721157ae682-8ae39c149d9mr20067657b3.43.1790976141498; Fri, 02 Oct 2026 14:22:21 -0700 (PDT) MIME-Version: 1.0 References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <87bj9c8450.fsf@HIDDEN> <CAF_DUeFczpGNNga=Up-NVydy6DhATt3JxTJMfqC4xQUZB3rTZA@HIDDEN> In-Reply-To: <CAF_DUeFczpGNNga=Up-NVydy6DhATt3JxTJMfqC4xQUZB3rTZA@HIDDEN> From: Jeff Trull <edaskel@HIDDEN> Date: Fri, 2 Oct 2026 17:22:11 -0400 X-Gmail-Original-Message-ID: <CAF_DUeH4dSeH60B9qtT2ETYJW12qCk3fz5VO5VPwRfifDVTbyw@HIDDEN> X-Gm-Features: AclHuK9KZRNLXZtAHSp4TQnsq50BZsPQIelWkinfA2n1G6HZTkUcIIhozjOt8hg Message-ID: <CAF_DUeH4dSeH60B9qtT2ETYJW12qCk3fz5VO5VPwRfifDVTbyw@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point To: Helmut Eller <eller.helmut@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000b7223a065ce220f1" X-Mailer: WebService/1.1.26668 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 4251 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 81970 Cc: 81970 <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 (-) --000000000000b7223a065ce220f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 2, 2026, 5:18=E2=80=AFPM Jeff Trull <edaskel@HIDDEN> wrote: > > > On Fri, Oct 2, 2026, 12:21=E2=80=AFPM Helmut Eller <eller.helmut@HIDDEN= m> wrote: > >> On Thu, Oct 01 2026, Jeff Trull via "Bug reports for GNU Emacs, the Swis= s >> army knife of text editors" wrote: >> >> > In PEG, an "if" expression is defined in the Elisp manual as: >> > >> > Returns non-nil if parsing PEX e from point succeeds (point is not >> moved) >> > >> > In fact, point may sometimes be moved. Consider this code: >> > >> > (with-temp-buffer >> > (insert "foobar") >> > (beginning-of-buffer) >> > (peg-run (peg (if "foo" "baz"))) >> > (point)) >> > >> > The position 4 (immediately following "foo") is returned. >> >> Note that in this example peg-run returns nil. That means that the part >> of the documentation that you quoted does not apply. >> >> If a match fails (as in the example), peg-run leaves point where the >> parse failed. >> >> In other words: the example works as intended. >> >> Helmut >> > > Can you check again? In my session (31.1) peg-run returns 4 (the position > following the partial match), not nil. > Apologies yes, peg-run returns nil in this case. But point is left at 4, the position following the partial match. peg-run is behaving properly - "if" is not. > --000000000000b7223a065ce220f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas= s=3D"gmail_attr">On Fri, Oct 2, 2026, 5:18=E2=80=AFPM Jeff Trull <<a hre= f=3D"mailto:edaskel@HIDDEN" rel=3D"noreferrer noreferrer" target=3D"_blank= ">edaskel@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d= iv dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Fri, Oct 2, 2026, 12:21=E2=80=AFPM Helmut Eller <<= a href=3D"mailto:eller.helmut@HIDDEN" rel=3D"noreferrer noreferrer noref= errer" target=3D"_blank">eller.helmut@HIDDEN</a>> wrote:<br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">On Thu, Oct 01 2026, Jeff Trull via "Bug r= eports for GNU Emacs, the Swiss army knife of text editors" wrote:<br> <br> > In PEG, an "if" expression is defined in the Elisp manual as= :<br> ><br> > Returns non-nil if parsing PEX e from point succeeds (point is not mov= ed)<br> ><br> > In fact, point may sometimes be moved. Consider this code:<br> ><br> > (with-temp-buffer<br> >=C2=A0 =C2=A0(insert "foobar")<br> >=C2=A0 =C2=A0(beginning-of-buffer)<br> >=C2=A0 =C2=A0(peg-run (peg (if "foo" "baz")))<br> >=C2=A0 =C2=A0(point))<br> ><br> > The position 4 (immediately following "foo") is returned.<br= > <br> Note that in this example peg-run returns nil.=C2=A0 That means that the pa= rt<br> of the documentation that you quoted does not apply.<br> <br> If a match fails (as in the example), peg-run leaves point where the<br> parse failed.<br> <br> In other words: the example works as intended.<br> <br> Helmut<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"= auto">Can you check again? In my session (31.1) peg-run returns 4 (the posi= tion following the partial match), not nil.</div></div></blockquote></div><= /div><div dir=3D"auto"><br></div><div dir=3D"auto">Apologies yes, peg-run r= eturns nil in this case. But point is left at 4, the position following the= partial match. peg-run is behaving properly - "if" is not.</div>= <div dir=3D"auto"></div><div dir=3D"auto"><div class=3D"gmail_quote"><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div class=3D"= gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div> </blockquote></div> </div></div> --000000000000b7223a065ce220f1--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 21:18:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 17:18:44 2026 Received: from localhost ([127.0.0.1]:40980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCkeS-00075y-AB for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 17:18:44 -0400 Received: from sonic309-24.consmr.mail.ne1.yahoo.com ([66.163.184.150]:39546) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xCkeQ-00075O-7I for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 17:18:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1790975914; bh=UsPQiD2FiyeU+eV/cDwyDVCnXDqfHL1qdhOE3YqzVlo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From:Subject:Reply-To; b=0+8ujoMFEn3efb9IWvcYN5VWREZKKAlEqvK2nSsv2xLDnjH+xHPeoYcDrLe0B+DHdxtAycZyo94JqTqCN+0GDQ/LllpsYSqHm450jgYryPVMoj6XiMABHtSUXaFL2Yvu+RYg61wbBkusiZLhtlCpx6amJBnD3Ygv/GUrz5eXj5w= X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1790975914; bh=Cgp28uKLEGMYKSD9FIycAFVF8XtUhfYozY2bPp33/ew=; h=X-Sonic-MF:From:Date:Subject:To:From:Subject; b=c5475AyL6KCK7phDNOCMlbmQmLumYG9R+NyUZGCl1zqDf6GIxQ1ELRIEzKNNEB2decpIIHj37BKfyzRH5/oA27+FWxYzO2jDVBqR0rMp6yBkLMhRS/3tM0/Pgv/Z7kpccdbbWB3XuoER+FRlg7TYuTxh5KjFdUdNvIhw20KGvKCO8anIsSwIVcFqNaR83Uttzjqpd8fENd9+f3hYJQgJRZ/X2ytlJ/JRy2GKEfsot2arqqB7gAOl7SjA2EKFj5UGmJbSAWD5JESMxo2o+aE7lBxT+bzqG4jXfYsW95+QgoG8WGSQPe+3rzXI/TiFXPn8cpvyaq1W0i/ybgfBcvx18g== X-YMail-OSG: B618yZEVM1kAIqx7JP6GpRJgVNLeCLD89xPQgjB8Y2j1bmevdHPzrjLB8Q9Jj69 WnZ137MNSJo3TecGbHDSNAWdSWF_ywPyDhAaKCqs0q3VMa8on1gFDrrXNtD23veuqLV6.L.dG3X. wCybuaytOnn19hnUIrtRbLcsAZbrZx0E1xZnVevNDNTAv_.MhrmRYIaYFP_0y7I5Blu5AN21B2QO LSeBHfR9G59maOh8P0x7iYYHj9mNMbyNqYr9fOVyJTfwL3r9JnRLKjNQHqt1aVEsSka02l.y4taX UhV5m6mk0H_jk_zxbNKLwGBM0YQ6ICeOXbi1o5tdVnCGWH0pgoLErPbHSpShKCTXmhyfBV90vxqC L9N3Ic4NJqHrYeEmxTc2yRoB9TEdL4p5ASWJXquBMYKaUCMLO66buW8J0z6AQ2V8kInXkEZ_J6pl dTGVKvEglv5sNHUuVmFoUCtcYWkRt5icq01Y8teE946YcuLxR6Phx9Z0EmSIaLLbMJUptMNLGnD8 thhK4ZRr8scDFNNWbDfJKj1Qx4PZ7iMkrBcJ7n3R2faoTo3mbIfR_wOOEOkroQbITGHGaDAmXvNX jJ.Theit0a8l7YYw3qHLXUGVaNbPQDVzBLNhv41tewA.ZdFwhEP.Gshi_b1C0mo8Ktqk_WFEe9uR dtcluxBNTo2Dj6sg2EibhiHVlBjZM0NsNxlNjwZe_eikAGSPvvyCLC7Qm1I_MQ.dCHDGFfXITvkT WNGHdiS7SU6DDsFKL31RiE4K0_NEyEL20qC9VmyH4P3GGtLM2LdjBlkSNB5NzKqkdeVrKVtIzzGn czfpNlkH8Pe7Ypa2W_rFMLIQT.zUU42qieRlsWg5ie_4eI7MnfkMXA6Ca0Q6uXyjBTtm27j04GPv _tIw36EsD8585WPtPBCBL5XMl1G6me1xR05JrJIlStcDnpMCGEa6h0GNeTz6zNOgMAcxOhfINkWW yQo1GD.zXd3sMg8jyafqXZ2Df_pyVsn8F94Vmcxpv0.YXOkmExStbO050E9i52cnQdJ8pEwE8d.a JBPNF9oNUGwJa9uL3q2dd7Pn69RIpwVlKoLTEwbYS7B8HcApMtiiyGfBA9oucXXCaHtE.DkotkwZ tns47pKURuDBkWsw7jZkVJqURiHeN6kMhc4jNFLpIaupaUcNZZ6W96H14S2qAY159QgWymtkpqvF i4wlIu1KOgihDPQNbwDMQeY4ouJECSbZtBZkYkLcPjWPWOfdTL18nxsEJr2awb8mupk9nNNGW0NR D.._U_8gQHiFg4DoI9r1oTymE0qvOOkbv6gSyB33Sg_kjf_Xz5IyJt1RsiG8TrV_M1HEDAP_mZ61 fLLH74vMGIstKMstY.pGhlycJVqihEtAv9SgX31sx9pqcDbTjDSi_dzK2Z8QXtw3JPvRkP4LTgRs hWA9Wa8bL2Rj0opRvIpUJQ_Qm2Eyp7hQodPeRLsF5uw7pPHzdfu.Iq34vOMPnFc5o4YRkc5dQjPY Zjh1fjTKShn2vHwkjkVCRg2X5OhgEO_Op.nbjOOEb.1TWl8rut7mzIzDTgYKDPXOV1NtrLmZNkg0 Kc4UiR7pkiAUda7cG52WkC9sn_yYk3oq7vhaDacwtB0gZkKpy7JnxeR8F2mF4JbAh3EBqwass5X8 0hxsRiIzz7tYhGHJELrJumCvjeqvakeyNih_qnXnn_D6tOvcVUcVjZ5GovzvruORS6KW4sUUo9Md 3_jxhtt0jeLtWUh0Bz4kHAQ2NEntGlnJ6npAt29IReQ7Po4gC53RnxA83nErLTethTJu4VLw2Pbh 52Cir8915D2BvErkldWEQvhpx12eZF8xvh_mnRUFvk.mCfQBnUbO00IcoEweWmkFeIlIuJbhGhtd vrqElhggzRCob9qOtQKtrMQvcqtK72vzgI5Zyj4X0EH_OnG7O4g49qbGNcmwJV23V5kncLAZtlxD GG.Z1NkoMeeT72jBCsK52OLugPeM0SlT7eA6nLwT6DtvC.pJR_.6301ThmUEPrHs3PbI0OjZqceV nLZRdoekiORxEHWffDDL.gwzJeQ6bJfsBSaZdVVgyN7R8feEfpWKGHKfggz0VYBsclxQIm8CGyNL cjwP1_Ic5B0t0I2h8BjGxXgpmA4hvd6dOVnwYnA6MZCDGuFr3.T0XfpDlzb40HrbU_Ap8pFKE.0C iYsUBthgLt0spXtr23P64NY6TFclRE1ocVlKXyiBA1frW8WjPBtDpz.elP228._bWrJyQCOT1PlG Q3wtT33rsmVFp2zPzzyrW_.ZbTzKT_UVJoAt6YY.oGzN9lktki38Yv18quH1l1eS5h3AlhJodwsk vaDTYzpM- X-Sonic-MF: <edaskel@HIDDEN> X-Sonic-ID: 1d008025-d07a-4938-88be-d4ac1ff34cd2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Fri, 2 Oct 2026 21:18:34 +0000 Received: by hermes--production-bf1-6d6877594b-nlk4k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a98bb9b6f7ddc07895d871519c08f895; Fri, 02 Oct 2026 21:18:31 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-8ac9d666d4eso4728917b3.3 for <81970 <at> debbugs.gnu.org>; Fri, 02 Oct 2026 14:18:31 -0700 (PDT) X-Gm-Message-State: AFq9FYLqLJkq5mQY7NL5OlrllbZv+3e5nVXPzykL32bY+FOlcbmTjnZs y+HJwJlz6WcVJyhrN04N8nDvUPp+iPTVRQkhxFFqdCQ0i42eiaquu8xIGtPEVif99XlqSXGwLQH EeTkz1XTmwbMnyPoK08NWhnP5Wgc9KnQ= X-Received: by 2002:a05:690c:a786:b0:8ae:6740:9ae with SMTP id 00721157ae682-8ae950f8e54mr3200297b3.79.1790975910484; Fri, 02 Oct 2026 14:18:30 -0700 (PDT) MIME-Version: 1.0 References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <87bj9c8450.fsf@HIDDEN> In-Reply-To: <87bj9c8450.fsf@HIDDEN> From: Jeff Trull <edaskel@HIDDEN> Date: Fri, 2 Oct 2026 17:18:21 -0400 X-Gmail-Original-Message-ID: <CAF_DUeFczpGNNga=Up-NVydy6DhATt3JxTJMfqC4xQUZB3rTZA@HIDDEN> X-Gm-Features: AclHuK8nDifEmX1DY3A41_KqH9YVI3-FJ4u_h4I-doIKFlJfKr53I_LQ7CGmmnA Message-ID: <CAF_DUeFczpGNNga=Up-NVydy6DhATt3JxTJMfqC4xQUZB3rTZA@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point To: Helmut Eller <eller.helmut@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000f221df065ce212bc" X-Mailer: WebService/1.1.26668 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 3113 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 81970 Cc: 81970 <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 (-) --000000000000f221df065ce212bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 2, 2026, 12:21=E2=80=AFPM Helmut Eller <eller.helmut@HIDDEN>= wrote: > On Thu, Oct 01 2026, Jeff Trull via "Bug reports for GNU Emacs, the Swiss > army knife of text editors" wrote: > > > In PEG, an "if" expression is defined in the Elisp manual as: > > > > Returns non-nil if parsing PEX e from point succeeds (point is not move= d) > > > > In fact, point may sometimes be moved. Consider this code: > > > > (with-temp-buffer > > (insert "foobar") > > (beginning-of-buffer) > > (peg-run (peg (if "foo" "baz"))) > > (point)) > > > > The position 4 (immediately following "foo") is returned. > > Note that in this example peg-run returns nil. That means that the part > of the documentation that you quoted does not apply. > > If a match fails (as in the example), peg-run leaves point where the > parse failed. > > In other words: the example works as intended. > > Helmut > Can you check again? In my session (31.1) peg-run returns 4 (the position following the partial match), not nil. --000000000000f221df065ce212bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 2, 2026, 12:21=E2=80= =AFPM Helmut Eller <<a href=3D"mailto:eller.helmut@HIDDEN">eller.helm= ut@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu,= Oct 01 2026, Jeff Trull via "Bug reports for GNU Emacs, the Swiss arm= y knife of text editors" wrote:<br> <br> > In PEG, an "if" expression is defined in the Elisp manual as= :<br> ><br> > Returns non-nil if parsing PEX e from point succeeds (point is not mov= ed)<br> ><br> > In fact, point may sometimes be moved. Consider this code:<br> ><br> > (with-temp-buffer<br> >=C2=A0 =C2=A0(insert "foobar")<br> >=C2=A0 =C2=A0(beginning-of-buffer)<br> >=C2=A0 =C2=A0(peg-run (peg (if "foo" "baz")))<br> >=C2=A0 =C2=A0(point))<br> ><br> > The position 4 (immediately following "foo") is returned.<br= > <br> Note that in this example peg-run returns nil.=C2=A0 That means that the pa= rt<br> of the documentation that you quoted does not apply.<br> <br> If a match fails (as in the example), peg-run leaves point where the<br> parse failed.<br> <br> In other words: the example works as intended.<br> <br> Helmut<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"= auto">Can you check again? In my session (31.1) peg-run returns 4 (the posi= tion following the partial match), not nil.</div><div dir=3D"auto"><br></di= v><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> </blockquote></div></div></div> --000000000000f221df065ce212bc--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 16:21:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 12:21:50 2026 Received: from localhost ([127.0.0.1]:48950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCg14-0000RU-WE for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 12:21:50 -0400 Received: from mail-wr2-x0f.google.com ([2a00:1450:4864:30::f]:36462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1xCg0x-0000Pj-LZ for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 12:21:42 -0400 Received: by mail-wr2-x0f.google.com with SMTP id ffacd0b85a97d-48b042e00f7so55209f8f.0 for <81970 <at> debbugs.gnu.org>; Fri, 02 Oct 2026 09:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790958093; x=1791562893; darn=debbugs.gnu.org; h=content-type:mime-version:user-agent:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=bi/2XQymF0CP282MlQ82/jji8eRej4Uj4Dt9O6xoxtI=; b=phl09Cr8RMiRkZfOg6oDEkHkbetH1YMF3C28u/ZQ1FPnAs0Q+7uurMh/GcXs+XtViF xJSBNH1fds1cciRwgYaEYmhyxeylVQ6t705zgq8NYVrKj7xZEyMgZeEUfbBDPyfaWLmi htJ5gKjqHMedWa2RECJNEPEqiLkGxQeRYS0ONFuj8YpTbLxA0mTjsaVRSwj4oAbj4ZJh 3oFv6ZCYIC7e0PWPxvsLNsGwUKBHkN35DN/i6c/6Br73pMmy0/kO8uJd+ayh5+n3bueF /YOuhfsQho0rcG7RQQ+P6fQgUF7aaukJFLo3S6yOwk2GU0PbILgl7zsC+mPwrFUvWlWh tIIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790958093; x=1791562893; h=content-type:mime-version:user-agent:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=bi/2XQymF0CP282MlQ82/jji8eRej4Uj4Dt9O6xoxtI=; b=SemH1yKmWGj5GB4SoVpuCV4atEh8thFeed5fl0LJjtD+sTmhDps9i9KtKws2VEgc+i rMFfsIsGROdBmKslSDQTd5cqq8wh+valkGnLCfcJsF8nEWv7BrBs80inMMYdMSXW9t9k 6l6cRlHtbTVXNB0qmgRipZNtY95c2a/v0Zj5lHwNTjzFg/eMzIO2Gl09951SEZFTrxP+ W1JHA5s6bpeWzQKqJX1bggzIUAreDgr7YmkLyE4j9Q9PxuQWUMZM75EcDKKS6S9kxq4m TuXCFuddFS9cdoUWwuwYhUG1IRL0mMIQmySZo9OxXUQP6PkbrNpmtdgVcWDumJF1+quO kGLg== X-Gm-Message-State: AFq9FYLxD6E54uLc4RJ1HcQozDQbbjGrPAharnK6uUkysJ2m/Dsd9HW6 xxmt5hEdOJyPv8wEPolTAUTiXi0hBlyu6fxloCbfTlCX3qTggjqXQz7ZyS4tpw== X-Gm-Gg: AYBFou0kORVa0/5tbnMpe7qHXZZVs8p3ieKvFYizEQ63nIyD2elUf3S+B/jjmLEgLnE bbpQcTlbFoJuVvCBY8VA05J7RM27YZxdV7Y4lL8fVHJFyj8RftKxMWvufmaDoiU3olSf47nC9C9 QBbTd63KH/MlM0J8voHc2yuJPEf/B5h8moFnKCAWrJGcwE2vh69x3dX81A0OnRkeswJG5I44YVj 6HeVH/fp5FxIc/dGizN3MCazQfTYDD73wCKajw2VIs69xZdr91RinShkyPfHh90E6EXlBgr+kcJ i1/IbChSDnX4RDYau95FSYLi16gnnmurG9Eq6P+DQmbX242q9NKhy1yX2QNdndhW+oFQlpQwm/Y RaMpLW7WvTeT8Rwc1dIJ6EXRhiYtZTZ1uSeuMTFwZ/hzyqZheipMCR3xzKgsQjDs4FN/U3jea0X EeF22U6xVXZ9+xkRetOWn1oe70kO0nuJkxwl5UlCCemzfCFMQ0UkY+kjCYHkbjfjs8zKdpVt/Zf 1LzmAfT24YM8ULsQdditcXAo120NQ== X-Received: by 2002:a05:6000:27cf:b0:48b:119e:dc71 with SMTP id ffacd0b85a97d-48b126bdcd1mr4451417f8f.5.1790958093067; Fri, 02 Oct 2026 09:21:33 -0700 (PDT) Received: from hessra (dial-189137.pool.broadband44.net. [212.46.189.137]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b38104602sm6946464f8f.26.2026.10.02.09.21.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2026 09:21:32 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point In-Reply-To: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> Date: Fri, 02 Oct 2026 18:21:31 +0200 Message-ID: <87bj9c8450.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 81970 Cc: 81970 <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: 0.0 (/) On Thu, Oct 01 2026, Jeff Trull via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > In PEG, an "if" expression is defined in the Elisp manual as: > > Returns non-nil if parsing PEX e from point succeeds (point is not moved) > > In fact, point may sometimes be moved. Consider this code: > > (with-temp-buffer > (insert "foobar") > (beginning-of-buffer) > (peg-run (peg (if "foo" "baz"))) > (point)) > > The position 4 (immediately following "foo") is returned. Note that in this example peg-run returns nil. That means that the part of the documentation that you quoted does not apply. If a match fails (as in the example), peg-run leaves point where the parse failed. In other words: the example works as intended. Helmut
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 15:21:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 11:21:40 2026 Received: from localhost ([127.0.0.1]:37056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCf4n-00051g-D2 for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 11:21:39 -0400 Received: from sonic305-24.consmr.mail.ne1.yahoo.com ([66.163.185.150]:40778) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xCf4c-00050m-1L for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 11:21:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1790954475; bh=4KHNgGefDeQLusFT06Q4SUFupykD1SjKDlSOr6I6jUE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From:Subject:Reply-To; b=u9T3ur9iMrxu06aZEU0EKHXxhb4MjCfTQJ96tUyP9uCRAu2ak1AcwDJ5pGv6SD5KyXODkgOjMOcfV0L99Q5lIkg38eGuW2f7kg3iAbBpYGPDUHY8ZKRmbh9sCcxwXwsliesEpIfIeYhMRG9EFThLSQBtRFGNuKWra7ogvv5HnOE= X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1790954475; bh=rwpvM5AOFnMBL12yo58vgfSipFhRs4VQnslKh0Zf6Zt=; h=X-Sonic-MF:From:Date:Subject:To:From:Subject; b=Udq5/1tnuaGiT1RlKFz26oAE8NwHawew9RdkyS8xaCh0JeeUAJyuBeg2qoWHDQLqcrmIr08TaGCo8Tn5BMSwuKE5ADBrTRkV80LcbecGzJNwKAq8r4gkZbzMQNtiUh7dEVsx+KHCCkCSxYS0TItzQcaGSJIdpwp2u7FSbm54awqHJSgq6L/kUn3ibHokGiZafLE3cvRsn+EGLvNBKUDOh+X50DZpvTF570GcXFP9EyekMufAElVecvIqtPau+WefTBpQk6MCzl87rlaPvKLRt5YR1ThO1dw1vN2pvLJfBihRGe+VMxDnah5zCQd/REk+fS6nAIOqZGxMUb8nLhASbA== X-YMail-OSG: s.6kl4gVM1kuw.Gscs5FJPCQBk.kDiEVMi4xnjy8MsQ8t92NDHiDRXmdJVsI1fo L9FTI.lCB1Ug.hy5k9QAKefoieLJ7hho3s1shr2Bwsrft2WuCie9G0zTro_BoBQAVDWrt37uBfew meqBAvsgAFOVKD_jL25pZG4N.shxL7nHSZJwDIPdc4wcUo1bzaobY.VOjl2XZvbvMrNzBRypgrZ_ aZCHMwAO_G8UVIhGqjS_T8D3PiAPVRPynCUU0HHsy980sdjH_YR05RHsLqlcRnR09Rpw27IapKxk aduhXEsVd2cW5TDmXH7m1dIedYwngQsL0ej0Nj5uukOhPoYlGPj33efiVwFS0eyDMBnYoE6v4LTm DqIPb8.JPPzzK15Visp0jXcgxmtA0ptfAaZ2Jj83W4HMfZOyrCsQDYI36repiZVBrl4sUjSzN2Md nfMXIAJBspqbcv9OTzaq5LZetsvWYaqY6Ljqd99_RnMMSf3GTrLK_lggZVMCChII7SbkwSCIo_.y 2j5nCUz1nRIa4f0n9PgyAGNvd9jCT5tWA6HNWHki4WXiE6mz7dfsk2xpTm7I7pFnMhf2_sUDGgxl NE6I7eeUx_rihS2EjfaYEAW5GjnaZ1hTYafLd0iGTZ5yw.xqxNpOrb_HX3W7ftwK_LuAeAOrS6lK tL_lg2MQt4mCVBdWyLwgtj2e1vaAZ4YkQTXSZtcovItOijy1tmpgt1iWLSbpho_VM4hZLW.lHGqB qxdxnu_JS7Hph7CtLLbIIyEldefxNZsRJccHY5K3oHGaek1f5K_dcr6T.IlDv7vy49ZItHnF8SbY YfBEaAHmNP2AVCwmQb0Dwb7hocdXr3AHOJV9LBDXhIr3_TWcvlyeDgGrFCExzdJlCowzONgv_ou5 FsTtq.oJJUk7_Kh95sPCcQ__3StvroEQrtuKuB5mM6s9eyWlwhrU6o9mh5I4katMBC45KTJSxkNF 56lu65XnQSXPCIE7K_XCweVGRcKmzGZVCXICIIDb8_G5WDJVVKmeX2lgS31hPB6wZFYMTxBByMH_ 0C_51iWixOF26z.cXx0W02awQdG8Z_xdY8DfDPRlreqFMJzD9Z.KSUBQVvGsv4pN6TAD4jEZdc_0 BJgPxG3.joBIbZCSynv4bTNXJHNEIlBGTDPNPi73n6vqMUffDpqYPrMy2wujQE.SI99.TfAaZGFs v8b8D3pKDGsvhaL5PtNBmM_btlOxUnVD68LXy6Bdbqix.H1U5XxAjXpk_uDbg7L3qkPjuAlqGBCz g.xKjgZSALXHcYVrf.fplzuaGtavdC5eFUHmsLG3TBrfA8Wl0Zb5IY7_JqntDLo38rAbnmPrRPwt hridSzsKfEHyrwGq1bq2PM4t_SW06gWS0L0nAQij2qpOEZkNM466Ylw3NtRdvqJHBZB1Mglqpqqz LJhMmXVn1mPp66D38nAK7oaRr5i9rbbBrDOmZOTpaScxqFxQwBd45HhRLUXBYgQaR66HkuUIp.II Ck1pJ9E5Qpg8tQquvbLUJ0tx3vWtyur9IL82K.XMIEwvMjflh17Im0VpOhhj3llkyBlshwnNfWsX iGZt5RHIs84kjCc5i1g3tEnGnDEm.6ucpylVhi0L3uCgiSV4yM0LBv55DuWjzNMwbmmQTVRUCAtg W1K7wmhR_Pw57tASyJ1x7PQ2LcxuSL.G_MWoDs88zxpgDIAfCc8hOCKiyRw84CTeTeZJ7vZ2gC.z JHtRQg6UjsnI6RDan0Ock3ZEAdyIfFdXgpf.uRe3tqdAuQ26jGiu4eUbboLHy3DsL8abY0YNS5bX 6im8MdYkbBThBJyIDHeqdWVYL3waBtlRas2_NrqfrIopKq941t7MlJO0vDKQZ5fNlowo0YmKgYSV 7iazUSYQm3c18MnGQ61qRnSRp.P6eAKOm0GrYVekL7HJJUiRc9jpvp.A72ewM19zm_d6udLLk_7D jJ5JFWIrH3c7qRHOynL3vmpKzKOzJgkJv5lhq1Lbm3FbkW3DT4.pPnQVAantGj.r_CDVlcPoygac kYQ84niyKgg1rEzW7QwQkT3qSu7qe2l_NuNKmyq11fOr2o1gU58KmZmCQAFZsmzvmVrGp.OWfiit CsW1abykpIUndNgv_maJWnhgt0LRhdiKB0V.N.f5dsP3EdZ_Kk0GoNIu2B_5IUn_8XAGFAaOdWQA c.M9dIrd.0EuMqGH6IGkB9v2pBIRtS4kpXcoZ88Q4WswtZr0jCx54_rla99wMjONzN8a_1WCG4Ly lDCNSFLyba9g4mlgU7N08Ta0o7yUxR3aM64ky05hpVvYjlQqJvYfibZskH5SOuXbeXJF2MNuBGGG XAaf7 X-Sonic-MF: <edaskel@HIDDEN> X-Sonic-ID: e38c193b-6ae4-4ac6-86a4-df5be7583e4e Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 2 Oct 2026 15:21:15 +0000 Received: by hermes--production-bf1-6d6877594b-jdbq2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 56b4cb43acf4e2a55b8ef4062f3934ae; Fri, 02 Oct 2026 15:21:10 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-8ac8a2ac52bso16607107b3.0 for <81970 <at> debbugs.gnu.org>; Fri, 02 Oct 2026 08:21:10 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBxbicd/g3yEB29NTUV5jyml+hH0YuZmcuCYewNAdAlXDSC0H+bW9J27GaxD2FdLeP290Da40Q==@debbugs.gnu.org X-Gm-Message-State: AFq9FYK4JHmw71/ZY1lk3uZLUhBGjEb2bYu7Ew2ewSXfBXbuWhS+Xstf 3344mBLgM6ycov/vXwcjTe9VGiB/qaWIXekssNOps0V1nNyzh6i/JEqLtKD03KPwomL88uWxUAc Cbbcsp87oQNH3XPvGIv9TcEjqcx95uGw= X-Received: by 2002:a05:690c:6e83:b0:8a8:316e:5973 with SMTP id 00721157ae682-8acdae8d683mr33107007b3.14.1790954468657; Fri, 02 Oct 2026 08:21:08 -0700 (PDT) MIME-Version: 1.0 References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <867bk0vgeg.fsf@HIDDEN> <1811201223.2671614.1790933487996@HIDDEN> <86ece8tlzh.fsf@HIDDEN> In-Reply-To: <86ece8tlzh.fsf@HIDDEN> From: Jeff Trull <edaskel@HIDDEN> Date: Fri, 2 Oct 2026 11:20:59 -0400 X-Gmail-Original-Message-ID: <CAF_DUeG1WGeNNQ-zYykzKd1Hp9Mkb29MEYWLVQLRdLO35TJCOg@HIDDEN> X-Gm-Features: AclHuK9yUT4uCdz35pvqh2yfzwbWYVIrMGQUxn5CIDFK27pzVVxOXbOjdAmtdoY Message-ID: <CAF_DUeG1WGeNNQ-zYykzKd1Hp9Mkb29MEYWLVQLRdLO35TJCOg@HIDDEN> Subject: Re: bug#81970: peg.el: "if" construct moves point To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000e9d219065cdd143b" X-Mailer: WebService/1.1.26577 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 5149 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 81970 Cc: 81970 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000e9d219065cdd143b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 2, 2026, 6:50=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > Date: Fri, 2 Oct 2026 09:31:27 +0000 (UTC) > > From: Jeff Trull <edaskel@HIDDEN> > > Cc: "81970 <at> debbugs.gnu.org" <81970 <at> debbugs.gnu.org> > > > > It's not "peg-run", but "if" that has the bug here. "peg-run" may move > point if the supplied PEG expression > > moves point. "if" is documented not to do so. Here's the implementation= : > > > > (cl-defmethod peg--translate ((_ (eql if)) e) > > (peg--with-choicepoint cp > > `(when ,(peg-translate-exp e) > > ,(peg--choicepoint-restore cp) ; only runs if e succeeds > (returns non-nil), even if e has moved point > > t))) > > Sorry, you lost me. Your reproduction recipe calls peg-run, and looks > at the value of point after peg-run returns. And peg-run is documented > to move point. What am I missing? > peg-run can and will move point the amount of the matched expression. This is sometimes a problem for writing parsers - you want a "peek" operation that tells you if the following text matches an expression *without consuming* it. "if" (along with its sister construct "not") are defined to do exactly this as part of a peg expression - to return true (matched) or false without moving point, as their documentation states. It's like "looking-at" instead of "re-search-forward", but for PEG. So peg-run consumes/moves point the amount of input the expression specifies. "if" and "not" specify zero, so peg-run shouldn't move point when called that way. I describe this as a bug with "if" because peg delegates the implementation of the non-consuming match to each construct, which uses the "choicepoint" mechanism for this purpose. The one in "if" seems to have a bug - IMO, the choicepoint should be unconditionally restored. > --000000000000e9d219065cdd143b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 2, 2026, 6:50=E2=80= =AFAM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Fri, 2 Oct 2026= 09:31:27 +0000 (UTC)<br> > From: Jeff Trull <<a href=3D"mailto:edaskel@HIDDEN" target=3D"_bla= nk" rel=3D"noreferrer">edaskel@HIDDEN</a>><br> > Cc: "<a href=3D"mailto:81970 <at> debbugs.gnu.org" target=3D"_blank" r= el=3D"noreferrer">81970 <at> debbugs.gnu.org</a>" <<a href=3D"mailto:819= 70 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"noreferrer">81970@HIDDEN= org</a>><br> > <br> > It's not "peg-run", but "if" that has the bug = here. "peg-run" may move point if the supplied PEG expression<br> > moves point. "if" is documented not to do so. Here's the= implementation:<br> > <br> > (cl-defmethod peg--translate ((_ (eql if)) e)<br> >=C2=A0 =C2=A0(peg--with-choicepoint cp<br> >=C2=A0 =C2=A0 =C2=A0`(when ,(peg-translate-exp e)<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ,(peg--choicepoint-restore cp)=C2=A0 =C2=A0= ; only runs if e succeeds (returns non-nil), even if e has moved point<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 t)))<br> <br> Sorry, you lost me.=C2=A0 Your reproduction recipe calls peg-run, and looks= <br> at the value of point after peg-run returns.=C2=A0 And peg-run is documente= d<br> to move point.=C2=A0 What am I missing?<br></blockquote></div></div><div di= r=3D"auto"><br></div><div dir=3D"auto">peg-run can and will move point the = amount of the matched expression. This is sometimes a problem for writing p= arsers - you want a "peek" operation that tells you if the follow= ing text matches an expression *without consuming* it. "if" (alon= g with its sister construct "not") are defined to do exactly=C2= =A0 this as part of a peg expression - to return true (matched) or false wi= thout moving point, as their documentation states. It's like "look= ing-at" instead of "re-search-forward", but for PEG.</div><d= iv dir=3D"auto"><br></div><div dir=3D"auto">So peg-run consumes/moves point= the amount of input the expression specifies. "if" and "not= " specify zero, so peg-run shouldn't move point when called that w= ay.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I describe this as a= bug with "if" because peg delegates the implementation of the no= n-consuming match to each construct, which uses the "choicepoint"= mechanism for this purpose. The one in "if" seems to have a bug = - IMO, the choicepoint should be unconditionally restored.</div><div dir=3D= "auto"><div class=3D"gmail_quote gmail_quote_container"><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> </blockquote></div></div></div> --000000000000e9d219065cdd143b--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 10:50:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 06:50:47 2026 Received: from localhost ([127.0.0.1]:48234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCaqh-00034h-D3 for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 06:50:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36288) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1xCaqa-000344-7x for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 06:50:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1xCaqT-00076W-4U; Fri, 02 Oct 2026 06:50:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nPVA9br7zF+KJHAt6F6K0nsiTCmkvh+PPmnMhZEgvmI=; b=mX5QK6D8XS6G JPvLanHokFSyYaFolpRMNGE2PaRzGwocx5X9jTU8GW87EuyuBWMybRx7jzPmmRpaUhdJH+KivWyB2 YOQjKktxARSzgerd2apvUl61xhLJjnl3pLTVGy2rdcfdBe8MbKPYl3w0KzELvsDeFG6ROGJyGR83Y wk3lIIC9hoAI4Cd0u07aSbSHKhgRMw4Wm3BMnaqsQHz1swyArYSKxIx5RuxR64ufdIdDf3J9YD+et 9whRVNxYwq0cB82LpLUezfmVttpn5d6jYkhxuMq9KjbrPYkh/Be6alFOcCOjDz0Yk0Cd67Q12UBl8 VAUB2nlHJgpCmGwp5m+1vw==; Date: Fri, 02 Oct 2026 13:50:26 +0300 Message-Id: <86ece8tlzh.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jeff Trull <edaskel@HIDDEN> In-Reply-To: <1811201223.2671614.1790933487996@HIDDEN> (message from Jeff Trull on Fri, 2 Oct 2026 09:31:27 +0000 (UTC)) Subject: Re: bug#81970: peg.el: "if" construct moves point References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> <867bk0vgeg.fsf@HIDDEN> <1811201223.2671614.1790933487996@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: 81970 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 2 Oct 2026 09:31:27 +0000 (UTC) > From: Jeff Trull <edaskel@HIDDEN> > Cc: "81970 <at> debbugs.gnu.org" <81970 <at> debbugs.gnu.org> > > It's not "peg-run", but "if" that has the bug here. "peg-run" may move point if the supplied PEG expression > moves point. "if" is documented not to do so. Here's the implementation: > > (cl-defmethod peg--translate ((_ (eql if)) e) > (peg--with-choicepoint cp > `(when ,(peg-translate-exp e) > ,(peg--choicepoint-restore cp) ; only runs if e succeeds (returns non-nil), even if e has moved point > t))) Sorry, you lost me. Your reproduction recipe calls peg-run, and looks at the value of point after peg-run returns. And peg-run is documented to move point. What am I missing?
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 09:32:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 05:32:01 2026
Received: from localhost ([127.0.0.1]:35298 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1xCZcR-0006Iw-FI
for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 05:32:01 -0400
Received: from sonic305-23.consmr.mail.ne1.yahoo.com ([66.163.185.149]:38745)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from <edaskel@HIDDEN>) id 1xCZcH-0006HY-Gy
for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 05:31:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1790933498; bh=49rVdzvLcrFxknxTjhpZ9/5giDVGKGAN+8lPj8DQjNc=;
h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=RsnBSnY9TNnP0FcMmETVjmVWlAxPHo3vnxzbpB9F3NmTvMobs9i09lvJZN4T0J3Ahm1q6LKXdNdzUYeusgUbTs2is3pk43810qP0b8SM8zK7jNeWwYSiP/jKjL73cJPRgCLIMnqWfFej08usVscyp6HUp+lWSwdnmshWS+dnokk=
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1790933498; bh=U2bEcqLaRVNg3VxMwwjZNjzAYuKl10gM13RVzh3ieD0=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=I9vlxETOiKKpKIY73EwQxtvKFCP82XVonHH9buEP9EnqkXR5XnPNCwUJdr1Qcd7IXTKaizUSSMDkzP/eTIgQ+zqV/kqA8Jx/Mnu9S5kY4CezKBkx/NABC1mNlL+irnxx1u0ab0sN3jIroIBFHAfhxOyVR2W5dujyKZPZF8J1LnzDez4VNwnHPl+YzAJPeIFljbrMkX9ggOUmg6CEHFxG1fvgJWGsB3zpnbtIxM/cX1aEQlHJmKWPBrsi9zXcBfwSWUf+gSsWiDuxf0+8xvw4kzdweQtWlKhSl7oVxwgE9A3h77PXS+r4le/jcB7OGQa8JNK1hJOPf8nMXoa4j3DnEA==
X-YMail-OSG: 8fbVpvUVM1n_NTWOMBsTUVHACCG2LGW9B310kuoHKP9KQpBPWXAAAM_B5Zb_PM0
XKfOtwL11yj_1Yjuafdd8NGL7G3qhI0N17Wb3JyYiGDBCQe2CckWFNA69Ox2FtbmbJylu8RCJNjJ
eKWs4eeNm3JUqe9o1sxH6_lOyOJPn04ezi0Fum8UrURwncC3p76uRDHsAJRCQ1qBkdDrmaW_a9jr
PmFtMR9Q4b4Y36wP0se5xoBKmb6.sKZn3hNxekTIPfysQlYDVprk_fftdPDviumFU3ast8DdaRT7
KOUaFM6SDvgBcD1wgYVY9JF.r1_e9CzsigxUSSNeny.c_L3DKXTE.zmfFNL7K.QXN7iiP4s9DAUb
AgxVB_PpViqt6H7bjszIa.N0gr68ISzrUlDgnRke7.TXWzE7ZaXFIbTezC16HKnG4nthNpK7fk_9
CICyuFjPwXs9kjqTcT_YBD2jU9.oe0HqRHEatUCNkSCDY_lIan0kb4uBwQCzHu_tEfwCKK0RFTIX
Ub5KZO_zqryTPY9FbG9FTXcrZB3fZr0POUJ1ysYpfLq713vwMjzqnAoOagp5diDDnrDS6enEFEtt
S9bBLGCQ4Krea5Ak_nihC_lJiQVFk4plYmBsez0zZp0saS7U8UPl8_VbF.PSxbtS2uOPF0MmBAJr
Wl_JRskhy0J5qJGzAvpg4e1qBPfEbXmxUSKlDUC3IlAAczzMlCyV9rWn6.exlFqBkNJ0RvXEk2Jn
NS4gpxvogTE1dJIBWdxQfBFHWP6Ceq6qwypIqJbTkzgcil0kgSDL.hSQXpm9wjopdoc8Wu0rjg8F
._8VBDKQejRw5bbltpbOII8SY6KAp0IlWLRtetJ1kfTz1vlmco1p9VebASIwTCyBprsi_ASs.8yM
K0PgeSmP_Xb3bkNdadkIH8IWa52nhZr2lgyy2e11m0lxI_Yj7s6NnpChKWfk8dW9m6HY1W3poo.Z
p3y2CItQJpQz90VAjgyFbqyXkL89dOhpaPTwaB4SbOSDrwJUEaW661eycAZLyxQt_1xdU9cT00gK
BlOpNVR0Mvba3EL22vPLw.lEARS5GUT2mUgxPB8wD3PJaNHkBtiq25cGjiBc4ek4uRogCHiq._gR
aC_dyYZobl5jDpRc1qT.FLTXccGSx5r2JV8jJhxhqKDEChN44SGxY4WtIj1Cj16h5HQuKUVN1H03
cmIoLKl_y2TlZRJ1wqPjx0OACvLIXJwN8A_zDBv3DsxxcVDRmDPMAJnlukaPBM0VFDwEuls_6ehf
2jpSvgU11WS9ECJHfVbiar4eidKL6MhqlseVxBTU2GuqZpVdW0PYRuEFIJ4VD1t0yjzTMHjA1msO
JgKDGjJH7KyeJcvQd6e6Ii28vyPlUFIc_l2A_kuNpNe8uPGlW8lu0YiQ7HwywYJsvhLZXiN2YK2L
_dH5NZEqYXjCZw49iSkxYK2C4HwNm.3.BZduZU9x1By2mXeQxsbkZD9jQ9Joo3WwkKU0taEm4dJh
E2QRqiljDteFZusoNfY3Zet7Osbt740FckoojN1aN1KHoJfhHTFadMy9LAAQJMWOe_cioadTflwy
1xCRGSYfmmo5pQd7.jFonaHsura3e0kNyuu78iNWt3UV7.q7ogR44m4daCr96iqUElZk.HDIl06_
B_PPU89nYQIfmvWH1u58b_dtYwRn.Jxl8O8CwO1YzAb3JFsGhAdg.gIOv9FUYpYp6g8NeGXq0mWM
EHiDCM6pXCG3BTyF9HirLDa9SESCleIst.yjtf9dX0c86ZMblPBq6QoOQsNvZat6k00VAgx0658E
bmuwcK5whcAxcnVRraHJUlFqvc7hNkag._11GnUUjT4fidGBtjjZDM1Rdno.jIrMOOGRRlB.dxYE
WS9eCK4YqwXjAVDsr4hPIyKw.33r3Sh5fb515kcRJV2eokSh.UDaloSa1HVPXCfkRvuh6qoNV6qu
MpqXxKsSfKrraQMYy4C4XadDk_8BL.KC2LdsO966WJlu.pFpg9ON.v44_FieIoS6.Ahi2zuwWWpU
ndl3atsuV2jhwx34x0Bu2P2ZTna4Jos1IbsL4e4Kbol4WVh8w1g6VLLinlP9iVAKv42q.Q4pkEhQ
XFy6_P9SU8APORhE_CacFRrWUduuV0PGzQbOzFAB3uBDmCepMb_.40LywEHb1qcnPxnJ7ELBhihO
fdnjweV8XBIlgxYZa7IdNIZzogje3BdgEEWTG.VzOFo7Ws9UjlsNRut3.1ordbYSAmZWHnhNiRBN
GA5m4sovJjStCgeY4OD9.KciaZ1YhmmDzJXz8W0A-
X-Sonic-MF: <edaskel@HIDDEN>
X-Sonic-ID: 4053df4c-77b1-4430-a3fa-91c9aeb095a4
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 2 Oct 2026 09:31:38 +0000
Date: Fri, 2 Oct 2026 09:31:27 +0000 (UTC)
From: Jeff Trull <edaskel@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Message-ID: <1811201223.2671614.1790933487996@HIDDEN>
In-Reply-To: <867bk0vgeg.fsf@HIDDEN>
References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN>
<CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN>
<867bk0vgeg.fsf@HIDDEN>
Subject: Re: bug#81970: peg.el: "if" construct moves point
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_2671613_852163944.1790933487995"
X-Mailer: WebService/1.1.26577 YMailNorrin
Content-Length: 5732
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81970
Cc: "81970 <at> debbugs.gnu.org" <81970 <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 (-)
------=_Part_2671613_852163944.1790933487995
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It's not "peg-run", but "if" that has the bug here. "peg-run" may move poi=
nt if the supplied PEG expression moves point. "if" is documented not to do=
so. Here's the implementation:
(cl-defmethod peg--translate ((_ (eql if)) e)
=C2=A0 (peg--with-choicepoint cp
=C2=A0 =C2=A0 `(when ,(peg-translate-exp e)
=C2=A0 =C2=A0 =C2=A0 =C2=A0,(peg--choicepoint-restore cp)=C2=A0 =C2=A0 ; on=
ly runs if e succeeds (returns non-nil), even if e has moved point
=C2=A0 =C2=A0 =C2=A0 =C2=A0t)))
The choicepoint is restored only if the expression supplied to "if" passes.=
In my example this is ("foo" "bar"), which partially succeeds (moving poin=
t) but is overall a failed parse. If the text in the buffer were "foobaz" i=
nstead, the child expression would pass and point would be correctly restor=
ed to 1.
The bug is that in some cases, "if" moves point, despite being documented n=
ot to.
On Friday, October 2, 2026 at 01:08:13 AM EDT, Eli Zaretskii <eliz@gnu.=
org> wrote: =20
=20
> Date: Thu, 1 Oct 2026 13:15:53 -0700
> From: Jeff Trull via "Bug reports for GNU Emacs,
>=C2=A0 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>=20
> In PEG, an "if" expression is defined in the Elisp manual as:
>=20
> Returns non-nil if parsing PEX e from point succeeds (point is not moved)
>=20
> In fact, point may sometimes be moved. Consider this code:
>=20
> (with-temp-buffer
>=C2=A0 (insert "foobar")
>=C2=A0 (beginning-of-buffer)
>=C2=A0 (peg-run (peg (if "foo" "baz")))
>=C2=A0 (point))
>=20
> The position 4 (immediately following "foo") is returned.
>=20
> I think a fix should be straightforward.
So you are saying that the documentation of "if" in PEG is inaccurate
or misleading?=C2=A0 Because the doc string of peg-run explicitly says that
point moves.
Or are you saying something else?
=20
------=_Part_2671613_852163944.1790933487995
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp6a50d154yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div></div>
<div dir=3D"ltr" data-setdir=3D"false">It's not "peg-run", but "if"=
that has the bug here. "peg-run" may move point if the supplied PEG expres=
sion moves point. "if" is documented not to do so. Here's the implementatio=
n:</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" d=
ata-setdir=3D"false"><div dir=3D"ltr" data-setdir=3D"false">(cl-defmethod p=
eg--translate ((_ (eql if)) e)<br> (peg--with-choicepoint cp<br> =
; `(when ,(peg-translate-exp e)<br> ,(peg-=
-choicepoint-restore cp) ; only runs if e succeeds (returns no=
n-nil), even if e has moved point<br> t)))<br><br=
></div>The choicepoint is restored only if the expression supplied to "if" =
passes. In my example this is ("foo" "bar"), which partially succeeds (movi=
ng point) but is overall a failed parse. If the text in the buffer were "fo=
obaz" instead, the child expression would pass and point would be correctly=
restored to 1.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div =
dir=3D"ltr" data-setdir=3D"false">The bug is that in some cases, "if" moves=
point, despite being documented not to.</div><div><br></div>
=20
</div><div id=3D"yahoo_quoted_1024050014" class=3D"yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Friday, October 2, 2026 at 01:08:13 AM EDT, Eli =
Zaretskii <eliz@HIDDEN> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr">> Date: Thu, 1 Oct 2026 13:15:53 -=
0700<br></div><div dir=3D"ltr">> From: Jeff Trull via "Bug reports for G=
NU Emacs,<br></div><div dir=3D"ltr">> the Swiss army knife of text=
editors" <<a ymailto=3D"mailto:bug-gnu-emacs@HIDDEN" href=3D"mailto:bu=
g-gnu-emacs@HIDDEN">bug-gnu-emacs@HIDDEN</a>><br></div><div dir=3D"ltr=
">> <br></div><div dir=3D"ltr">> In PEG, an "if" expression is define=
d in the Elisp manual as:<br></div><div dir=3D"ltr">> <br></div><div dir=
=3D"ltr">> Returns non-nil if parsing PEX e from point succeeds (point i=
s not moved)<br></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">>=
In fact, point may sometimes be moved. Consider this code:<br></div><div d=
ir=3D"ltr">> <br></div><div dir=3D"ltr">> (with-temp-buffer<br></div>=
<div dir=3D"ltr">> (insert "foobar")<br></div><div dir=3D"ltr">&g=
t; (beginning-of-buffer)<br></div><div dir=3D"ltr">> (peg-=
run (peg (if "foo" "baz")))<br></div><div dir=3D"ltr">> (point))<=
br></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">> The position=
4 (immediately following "foo") is returned.<br></div><div dir=3D"ltr">>=
; <br></div><div dir=3D"ltr">> I think a fix should be straightforward.<=
br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">So you are saying that=
the documentation of "if" in PEG is inaccurate<br></div><div dir=3D"ltr">o=
r misleading? Because the doc string of peg-run explicitly says that<=
br></div><div dir=3D"ltr">point moves.<br></div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr">Or are you saying something else?<br></div></div>
</div>
</div></body></html>
------=_Part_2671613_852163944.1790933487995--
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at 81970) by debbugs.gnu.org; 2 Oct 2026 05:08:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 02 01:08:20 2026 Received: from localhost ([127.0.0.1]:53006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCVVM-00055B-Ez for submit <at> debbugs.gnu.org; Fri, 02 Oct 2026 01:08:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34222) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1xCVVJ-00054X-Ni for 81970 <at> debbugs.gnu.org; Fri, 02 Oct 2026 01:08:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1xCVVE-0006WS-77; Fri, 02 Oct 2026 01:08:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pnHQsTABQaOi0D0idluEVgaS8R5/DD0owSoSmKZa3kM=; b=EZVHPtsNztUz 1H3Y0lhK9mda7SdPShmWtBj57sccQ+TDw/umTeCmYSPiAyuMsBOoyGFFREvR/utAGhMJH/v5DCcCC g2fdMbpgyT0oRmuhyZ6rIlhilD5b1A+7J0uidEJj5qd6DKSpm6EKyfAjjmo2+ltpYY5pODVwSDsld 4XHy/YxkJZQrY4HDVrs8M4wptaaBaPRKdTGvptQElj9YV9kWnkbdm1uZkYvIttgjGkmX+rwRy1XO9 uLxmOm+4rzDiuU9EfTzVXGni6MeVLR/UXpyTGXN00+dgyfJGL6lOW8jxr5NaMjIUNUxQDgsSR5bFU 4EQCovUofgtVmNSeyl0H4w==; Date: Fri, 02 Oct 2026 08:08:07 +0300 Message-Id: <867bk0vgeg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jeff Trull <edaskel@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#81970: peg.el: "if" construct moves point References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81970 Cc: 81970 <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: -3.3 (---) > Date: Thu, 1 Oct 2026 13:15:53 -0700 > From: Jeff Trull via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > In PEG, an "if" expression is defined in the Elisp manual as: > > Returns non-nil if parsing PEX e from point succeeds (point is not moved) > > In fact, point may sometimes be moved. Consider this code: > > (with-temp-buffer > (insert "foobar") > (beginning-of-buffer) > (peg-run (peg (if "foo" "baz"))) > (point)) > > The position 4 (immediately following "foo") is returned. > > I think a fix should be straightforward. So you are saying that the documentation of "if" in PEG is inaccurate or misleading? Because the doc string of peg-run explicitly says that point moves. Or are you saying something else?
bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 1 Oct 2026 20:16:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 01 16:16:44 2026 Received: from localhost ([127.0.0.1]:49865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1xCNCt-0002vD-Ni for submit <at> debbugs.gnu.org; Thu, 01 Oct 2026 16:16:44 -0400 Received: from lists1p.gnu.org ([2001:470:142::17]:44206) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <edaskel@HIDDEN>) id 1xCNCq-0002uT-F4 for submit <at> debbugs.gnu.org; Thu, 01 Oct 2026 16:16:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <edaskel@HIDDEN>) id 1xCNCT-0002sP-PQ for bug-gnu-emacs@HIDDEN; Thu, 01 Oct 2026 16:16:25 -0400 Received: from sonic305-25.consmr.mail.ne1.yahoo.com ([66.163.185.151]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <edaskel@HIDDEN>) id 1xCNCR-0007n4-P4 for bug-gnu-emacs@HIDDEN; Thu, 01 Oct 2026 16:16:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1790885770; bh=qydWiLcy4pJglM/9S9HTM3971MnQV4IlRHazl03axqg=; h=From:Date:Subject:To:References:From:Subject:Reply-To; b=C6CjZoIu0/0C4fWytZga1fjMQNsxLF7/vMZwSkO0XtSYEYt4BE2GBPeFXq+U5AmQ1lUbbhNrZfurjspLeWiDLBgVYbbVbGMz70nuZdrQ5UksKNse4qXNYJhL03VQJGQNEOUKJ7NQv8JvQJ4nKAgwLuClYrfT4sTL1zljCa+xgYY= X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1790885770; bh=/eTTwwhyf3eLzYzZpS6mXdwFMEiSXl/i0Ps4Z3ZD59U=; h=X-Sonic-MF:From:Date:Subject:To:From:Subject; b=JcPPZ9f6EDyRC1V72/JfKCYxDNFLKA7E1yDejI4CXGsRvKP0pLusFbPKZsXxee909iF+GSdp4AuY/fI7ReCYNeiM0HKtIdGDoPUNskkQJSmlxMuU0GkM16kPpHdhCrcEJ1+m20vHkxwFyY5YWSQRlMGmtOjPGOsL0xrMvuWJixhOwJkrF1/sSGr2zmleqpLoHhfd9gwMddyjPe8Bj1jO5cgOJ8QRmGy+Wp/83uGxYVGZ/7qx5kllndlam9IrrFOA00FAOJZOHnQXbQ83l6vGdudJWFyjQ3w/ffI8CAsicM7pDCm9dqYsW+cXSRKkT15Z6fANlDHwzqK5kHFk7jtHog== X-YMail-OSG: LQF2HoEVM1mLip6JgDtAGryRUs_OqqGM3C0pXFH80rQlL78UL6UfMoJgn.y1O.x GKMNKNbcXnRBgHTuHu9E_ZMQQEpunpqH6PR.Yh1qu9irBz.vdJGuiQjI77Z0nQ4wGxN28_c_pabl Ca5aXBNbjz6FhoetxlzM0CBdf_irVX7l.BrQcDgMaYMuxHqJfzsHsAkhcJ.onyGOp2VGqTumE3zp ScL3LufwOmL0dGH3YxVy6Ao2D.pB.Jb6o8yNuWcm0omredAYPS9kj0VgNxsxqbST6GY8NRr_Q_Ua zocJoLpHUxvRtJu74dw3gG7OjkaIoBMKIxoYutplUPR2uoYice5W4W9snqTJbfeT4NMiTgSRcaw_ ynZDxT2Ag17E7jJg5MZwuyH8z.e1D1dTtuZmif9GNyTjjXLePEBmE0YGgpdKkWS9hznwv6Noe.QJ TvmHEV4w6m.nGC5URa7oZqmlgB9v61wiO_1.f2rjmkE8isi_bY82qt2e08XBppXxxzq.y47vYYz0 e.vRxXLmq32Auxr6PwuqfdlkLnHz9MwqsoQQr7gDpDojwQW_xtSNPK5okL1en2vepA4yr1AajTS8 qMpx9LpVDPx1X0mJmjIaip6kF7PAUgrs6jV_2s8uq3phREkRQM.rqd.MVbE4UKMCW02_kc_fuGel 0EIT_RMd6x6cBR3HrNTLULJ40wa6TWpILmKGkEPoEQv6qFHnspJcWYfp6vg0SMXNaXW87SKmBDHZ X1F9Bje0IhggJA32TJ_rpfrK2RstMcCgE0Hhd8hSOU0henLdc82Sy.hxQkY13YRKhVIvZu6tqN9X BBAIimm8IRqtiYqAPpqmLhmWPeWIjwwiy32_uiLNSx.uuVPW5UShT7ZGtqZmP5q8izpPqOLMJVEP TzgrK_dclSxFFKUtz57789hCEyY78XJfYfrUnCC4TXWU4B8ACd9AEPmS2yuq5hTqz8ttGapYijD8 RqB1KcS51CZh2TrIht45MibKwDwqG6jAHneHx6HXQAkaFjz7Nf1vvELqSIlOd5TCD3MrTmFaxjek oC8bh.dYlKUx6nNs3UUCzU90mZ.hAvFjkjZwy9.wEG6B5JVsd6zvgavLh2WP6D9wN.mNmUpjpWId 6ycsLa24W4kQ._jnvMvfE0oxGjqJFvQvFD2jk8EAniZRRz2GIlI2RRn3ArGXwD4TruzfYvBPKPRK hWrjN.g_9.WWvNxhtbgdYK2DwMM_0V6z2hNQVnZKiqkRudnmqqnhOmOKb3IgAu8N6bgfVp39v9NO eLmc_dK1d2fQm3GBMf9.gTSjGvMoKNEi7eme7f4MaKD853GknynLD1.dwZN3EHXAuK9tNexrJ.mc 0NpqOuzCAjSIoU7pQwy0U3p.bciaYT0BDbKS60BiekMWEMpjsQ4l.XMmgTvJxUgM9lxgqZLZwpsK Kfz_qyO.aJZ0rxCWMNoG1qgZl8pDsmfJ1Q2YHaFars02jqVEVUjnxr8ReRcGjCkOdBKefyqRjSab oi2v5AKQ_n7q3BIpMSITuBXNlZeEu_GGQFOn0Qw8e_omJVg7jTd9G1S5uSW7hQpro6IqyCCk6iVy cOD92xrcOFHHl_JHNM9gUOdOU7MTkgYdrjUceaWXaE53f_mK3Zvo8slBKblxDKEHcoqhLXil88TD WlMwtfT2zlNvkVAK8XtOPo6LEz7sJJlidhJUOCRUI2LOFGBXqQ6.FbPKrJGO_eLkE8ri9zcNS8ax VEkE.gGzmaqWcvBpOAed9i1YGI7rB76bb6dk5Mrqyhpk4Dv2RWsxk0gO04mzG3yB1FHX1rwyJ96G GOfdn6B5yLzzM5VXIizklbM61Y1o3OfgEmREnz1y518c1oYSuo_hMvWKw3Esbg03lbml49MKbe5H MPWkvxF7w4NGOAqTHeAqePWNB8Lfc9veUBy6RHfkr3b_IuKiMDewiCklic1xkUpGMroQfLF9Ylxw IVIQG5S3AcQSg8lcfPpzyoSl.GsG_N8MTjeolztJQHLqyoYxMkMyVgk7nyAWBCtJEQIHRfUZYjzm qNFbLTYUzk7ti6.E.TVy_I_RHtHBZxf5q146mQmoZNGl8p3h5kdaDh0guiX4A33NNohrI936i5Gf AlBxYDao1BnB_h5aMbU37EbMEO8sCqS1nPbGQUar.4qrdfgeBo.Sz1P69Z9u0gXKe0mE6jGvAJTU tzpBFBNMigVJA1uINfKsnE6XrRcX8.E9X_ujVnv16e2eg7JE5h120OOebSrBuPFYNA3c8ifIb1KX sBKBeRPJ0D2xrpacabmBqwlaTdKJclfIkbIvirGGnekS4_BXNf_UH3U.A X-Sonic-MF: <edaskel@HIDDEN> X-Sonic-ID: ad47ced4-8f0d-4546-b251-4976d352da2e Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Thu, 1 Oct 2026 20:16:10 +0000 Received: by hermes--production-bf1-6d6877594b-qr7mx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a9be4dc229571ff1e875a15824d02f5f; Thu, 01 Oct 2026 20:16:05 +0000 (UTC) Received: by mail-yx2-f40.google.com with SMTP id 956f58d0204a3-675686b026dso1524035d50.1 for <bug-gnu-emacs@HIDDEN>; Thu, 01 Oct 2026 13:16:04 -0700 (PDT) X-Gm-Message-State: AFq9FYIe62tIQziWBLmQifqurbDfRz8y3dghHjJVsA99LUu3dsiFF+i8 JtRuxpq9WW+ERRv8JMWnLCgZ+UuET9ext7ecCXU/cEINW3G5XEfolrSp6C5Wv57lKnuHcDiaOn4 PEcWqdVbifVReGbDorl5fflMYVHdbIWU= X-Received: by 2002:a05:690c:5681:b0:8a4:af43:6941 with SMTP id 00721157ae682-8ae3a7e8e51mr1525897b3.20.1790885763983; Thu, 01 Oct 2026 13:16:03 -0700 (PDT) MIME-Version: 1.0 From: Jeff Trull <edaskel@HIDDEN> Date: Thu, 1 Oct 2026 13:15:53 -0700 X-Gmail-Original-Message-ID: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> X-Gm-Features: AclHuK8xSyhyy1pGt9yBSMHfZuzRNlfyjofT-2YVcAy33T4rdPDxDp6gnAUppe8 Message-ID: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A@HIDDEN> Subject: peg.el: "if" construct moves point To: bug-gnu-emacs@HIDDEN Content-Type: multipart/alternative; boundary="000000000000cbb29d065ccd1589" References: <CAF_DUeFtCcdvkNP_R9NOzzBpAcpxOgkVsxyEApn9DJmjxDoy7A.ref@HIDDEN> X-Mailer: WebService/1.1.26577 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1480 Received-SPF: pass client-ip=66.163.185.151; envelope-from=edaskel@HIDDEN; helo=sonic305-25.consmr.mail.ne1.yahoo.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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: -0.0 (/) --000000000000cbb29d065ccd1589 Content-Type: text/plain; charset="UTF-8" In PEG, an "if" expression is defined in the Elisp manual as: Returns non-nil if parsing PEX e from point succeeds (point is not moved) In fact, point may sometimes be moved. Consider this code: (with-temp-buffer (insert "foobar") (beginning-of-buffer) (peg-run (peg (if "foo" "baz"))) (point)) The position 4 (immediately following "foo") is returned. I think a fix should be straightforward. Thanks, Jeff Trull --000000000000cbb29d065ccd1589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>In PEG, an "if" expression is defined in th= e Elisp manual as:</div><div><br></div><div>Returns non-<code class=3D"gmai= l-code">nil</code> if parsing <abbr class=3D"gmail-acronym">PEX</abbr> <var= class=3D"gmail-var">e</var> from point succeeds (point is not moved)</div><div><br></div><div>In fact, point may s= ometimes be moved. Consider this code:</div><div><br></div><div>(with-temp-= buffer<br>=C2=A0 (insert "foobar")<br>=C2=A0 (beginning-of-buffer= )<br>=C2=A0 (peg-run (peg (if "foo" "baz")))<br>=C2=A0 = (point))<br><br></div><div>The position 4 (immediately following "foo&= quot;) is returned.</div><div><br></div><div>I think a fix should be straig= htforward.</div><div><br></div><div>Thanks,</div><div>Jeff Trull</div><div>= <br></div></div> --000000000000cbb29d065ccd1589--
Jeff Trull <edaskel@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#81970; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.