Received: (at 50236) by debbugs.gnu.org; 4 Aug 2026 12:55:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 04 08:55:01 2026
Received: from localhost ([127.0.0.1]:38211 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wrEfc-0000DF-Ge
for submit <at> debbugs.gnu.org; Tue, 04 Aug 2026 08:55:01 -0400
Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:47123)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <ahyatt@HIDDEN>) id 1wrEfa-0000Cz-0i
for 50236 <at> debbugs.gnu.org; Tue, 04 Aug 2026 08:54:58 -0400
Received: by mail-wm1-x32b.google.com with SMTP id
5b1f17b1804b1-496bb7cdf51so34033395e9.2
for <50236 <at> debbugs.gnu.org>; Tue, 04 Aug 2026 05:54:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1785848092; cv=none;
d=google.com; s=arc-20260327;
b=a3WGoJtA+wmUkyDXBD+iZdGmZci3yd5VfjPQSXo3+3p6BJ+nB2eqnyMHTwk4CnQViR
GLqxQyYOEeULTJSn/pIqqxzTvnHZR+mgYCw2uvG+/skZ1qzkZ7o7xIOzoEZGJ4fcmwQb
fKKog3+VEAVG+e2ty6jEjelELQ8DAIM2NViAg5yAxShwu5JDezKMoh7Kd/VoaBqDU+vd
WYBPTw4Gjzk87t8rbLVvN9ZSbqd44puKyHQeNnysD0aaPwlxPNe31+e22epSI8UI34XU
7H1KDBHrlWqY9ZZdEawd/vG6ngDCNCt99R7J7mDw1og2sEqMv8sEp12r5phbkr1X5DXL
qPwA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20260327;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=kkPWXx/NlFHE5zuA0BKyG4U4XhBW3EpMWszrVKlSNa8=;
fh=BC3zzlc0/kO/k4jkKpT6CuiFeZqQimIzxuZlmn20iI8=;
b=licZ3o5pPvzUjPDJFhfp8wkWsHFRD32Ylq9iypL/8XEAmiQZm4CwJFWjRUU52hrEcP
BTwt9H4agjSVPS+mMsj5/Pl4ZyZ03FrTv+6di/DEnEKWOFB04eJ86oOfyzASvOwCT4DE
8AWpH8VXP6eqxFe4s8GOAZ/soAQowgCBvEFlAINRkXCTuRR9+znDIAOEnJOv0eqWdVuO
DXOJ33UCl5Ly9ZuOtguvKnqeOmpYppdskIKRcydIN8zgH9Hgje/17UaCECkPIlcGdyAK
/BkvMyLo+t9oVwdtfUFU4ZENBTx8XfmbwGKea2VcpqJ2A589mpaBo0CEIFdeBBopfXCX
ZLXA==; darn=debbugs.gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1785848092; x=1786452892; darn=debbugs.gnu.org;
h=content-type:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:from:to:cc:subject:date:message-id:reply-to
:content-type; bh=kkPWXx/NlFHE5zuA0BKyG4U4XhBW3EpMWszrVKlSNa8=;
b=gg0uMx2dfiW9QLIPhtHp1/HdMrr0mkPz2/Ijf7XH6Fh6pFU8tUBff9AxApopt8+ctC
gdbDWR0S6Ng1ukXBPDPxH81PRhLbF9L+eUltDT6Oh8KlEmtE+IbuCSaVzQWyyeWB5zsT
Rxr6fgC9DnOpKvORAdrCFUhW+yjCwTNItjG95YfqjA7+3ewt4FnRgimdwPR/H1mKwLse
wbitkvnpE8FTD31alnTOJXgdil2uwHNHw+5iefdY1o6JpojjczREcdHzLkq54RPoVv58
velmoTZ9SES1EPwkT/ed1VDqwONbR0Yj22niY5AdWzpQC8Uhwrg7KAQ/UuLFpacPDJuZ
oByg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1785848092; x=1786452892;
h=content-type:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to:content-type;
bh=kkPWXx/NlFHE5zuA0BKyG4U4XhBW3EpMWszrVKlSNa8=;
b=n/0tT6bnVWvkIueb2ibkArSrSUYKCpT/6PBQ2sezKf/F0UuwPyY1GI6EBYbYRJkv8F
2Nnnt5XnXo/9psR//kuago9FOamLtkxFeEhsn4xPgNoENZ4QDPbFe06aDSoF4Ps87IUA
H5VWZN/4+JvCxTW6gshEfTZg1f1V3gLSEuVzMaZ+bV/hKS9q7LqDCxczFjGdqNRZyMl4
bGgL9YeK3EbtA/ZdIR67q+EOmtTb9O7PAENM1VXmvbqMdpzuFGB0PfU0oOJ9DoUyK+Gq
RM/cm+HOlSxpqwt6SfqvFTvPw5CEPysbMx3sD0F/IT7PcvyYZ9T3t43LFitK0cpnyl+F
J4ow==
X-Forwarded-Encrypted: i=1;
AHgh+Rr1QiHOW0x/FzDTghMg4S3IkB0DmiOdRGx3p8jNkQd5mLoau2hV1iDFEyj1M2oomhEGivsHJQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzBPKRQ8ly2iSIbK6QtEUZ3Zm8ZAvwhYZfbD+1D4rRTZEIBe8YW
gFZti8k9Y9MAd6/MNQ5tIncz6L7uYEeK6krB5XFQ6NSKGVp+wwQ8TAogBYzAtzmC5m5EAMCDfY6
AKxfkAvzh9rOLoh2uVdDn/BkYQiI2ARU=
X-Gm-Gg: AR+sD13Mq6GQnYf0tRpG0kBbjNsp9QQQMcpHXOFE1VTIim05AXGOGmN6vWgvHj292eS
M+XQoVWN/6ZXU5om7xOBXu7P0CVfSIPgppz/XhO0IMt4Bxbmpt3iDl/eaeGPuDi4TOY8q2piLfu
z9+4abCKO5VGUGiwp6fZlSVXgTIL+/XDi1DWzuaGCjYQ6cPOPbT3Bt7XJRuOvWth3kXKH7COmPJ
4a9r7FeH1AQqhP3mOrfrrXU54FlUwB0+Qzp6RFNAC3qgjoph6BgrHkZH1lf6vMQ0SnrXVVDUTje
t1/A2CDzxbV562U96xAP+Iq4rDxcqyDEm6NcypSDfzUEr4a2WpWv4Kk7ETRa4uNWhmxrDwR5i2b
fqn625OHB3EMwOr8Wqb5PWshGMBs9tvEnZOgJbyLyIP+jm+aVS1dYARs9ey4=
X-Received: by 2002:a05:600c:1908:b0:495:7838:7e25 with SMTP id
5b1f17b1804b1-4980ee9f00fmr315574085e9.15.1785848091519; Tue, 04 Aug 2026
05:54:51 -0700 (PDT)
MIME-Version: 1.0
References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN>
<87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN>
<87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN>
<m2qzl2bfi3.fsf@HIDDEN>
<87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN>
<87wlur4cjr.fsf@HIDDEN>
<m25x2aacul.fsf@HIDDEN> <86cxw2i5s7.fsf@HIDDEN> <m2o6fk6l6n.fsf@HIDDEN>
<CALDnm51D8vExcstbKEGPNdxgtpMQXc_eNg8MqMDiu+Xo9caLqg@HIDDEN>
In-Reply-To: <CALDnm51D8vExcstbKEGPNdxgtpMQXc_eNg8MqMDiu+Xo9caLqg@HIDDEN>
From: Andrew Hyatt <ahyatt@HIDDEN>
Date: Tue, 4 Aug 2026 08:54:39 -0400
X-Gm-Features: AUfX_mxYsaah84aycz7l6ZVaUMeYSPUrSGmKtituT7-VmphgUgmaYdNl4C1MRlI
Message-ID: <CAM6wYYJx60-UhCaXyh8tkbi0aOk3dtHukUVOuiLbFAcu=e=_aA@HIDDEN>
Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001e376106583829c8"
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On Mon, Aug 3, 2026 at 5:37 AM João Távora wrote: > Did
someone test the candidate code with SLY's current e-p-m and comint > integration?
Is there any reason to think it might break? I hope not. >
Content analysis details: (2.0 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (ahyatt[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2a00:1450:4864:20:0:0:0:32b listed in]
[list.dnswl.org]
0.0 HTML_MESSAGE BODY: HTML included in message
0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or Formatted
Colors in HTML
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Debbugs-Envelope-To: 50236
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
50236 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>,
Ihor Radchenko <yantar92@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--0000000000001e376106583829c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 3, 2026 at 5:37=E2=80=AFAM Jo=C3=A3o T=C3=A1vora <joaotavora@gm=
ail.com> wrote:
> Did someone test the candidate code with SLY's current e-p-m and comint
> integration? Is there any reason to think it might break? I hope not.
>
I think as long as SLY doesn't use fields in some strange way, it should be
OK. I haven't tested with SLY but if you let me know what e-p-m is and how
to test it, I can test it out.
>
> If SLY decides to migrate to the new style of comint integration
> (presuming there is one, at least that's where I saw the discussion heade=
d)
> is there a manual or example to follow?
>
I don't think there's anything SLY would need to do, as long as it is using
comint in the normal way, which automatically uses different fields for
non-user input and prompts, and user-inputs are not in a field at all.
>
> Jo=C3=A3o
>
> On Mon, Aug 3, 2026, 02:35 Andrew Hyatt <ahyatt@HIDDEN> wrote:
>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> Ping! Any further comments or suggestions?
>>>
>> In case there is not, I'm attaching a patch for the complete change, now
>> including a mention of the behavior in the manual, and two new tests.
>>
>> From: Andrew Hyatt <ahyatt@HIDDEN> Cc: Ihor Radchenko <
>>>> yantar92@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
>>>> 50236 <at> debbugs.gnu.org, joaotavora@HIDDEN, eliz@HIDDEN Date: Sun,
>>>> 19 Jul 2026 17:28:18 -0400
>>>>
>>>> Augusto Stoffel <arstoffel@HIDDEN> writes:
>>>>
>>>> Hi Andrew,
>>>>
>>>> in your proposed patch, why did you choose to change
>>>> electric-pair-post-self-insert-function directly and not
>>>> electric-pair-default-skip-self (or even define a skip-self function
>>>> specifically for comint)?
>>>>
>>>> Isn't skip-self for avoiding two closing parens in a row? This doesn't
>>>> seem related to the problem.
>>>>
>>>> Also, I should mention over another solution that Jo=C3=A3o had previo=
usly
>>>> implemented for Sly, discussed on the bug I merged into this one, this
>>>> issue can be partially solved on `comint` or other mode side by markin=
g the
>>>> non-user generated text with a comment syntax, which electric-pair alr=
eady
>>>> skips. That solves the issue that program output in comint can mess up
>>>> balance, but not that two separate inputs should have independent bala=
nce.
>>>>
>>>> Maybe that's okay, but then it would force other modes to solve simila=
r
>>>> issues by using field properties.
>>>>
>>>> I think that's probably a good idea; using fields to represent
>>>> different provenance of input is a good general practice that electric=
-pair
>>>> and perhaps other modes may come to rely on.
>>>>
>>>> I've added Ihor to the discussion since the issue affects Org mode as
>>>> well (see my email of 22 Aug 2022 in this thread). WDYT?
>>>>
>>>> On Sat, 18 Jul 2026, Andrew Hyatt wrote:
>>>>
>>>> Augusto Stoffel <arstoffel@HIDDEN> writes:
>>>>
>>>> Is the search bound (and attending local variable) really necessary?
>>>> Text property search uses an interval tree so it's better than linear =
time
>>>> in the character counts.
>>>>
>>>> I was able to construct a buffer that, without the bound, took tens of
>>>> milliseconds to get the previous field. Basically, lots of different f=
aces,
>>>> etc, which requires a lot of iteration. I'm not sure what the normal
>>>> expectations are, but I thought it best to err on the side of making s=
ure
>>>> everything stays optimally fast.
>>>>
>>>> The 1000 char limit is more than enough for normal comint use, in my
>>>> experience.
>>>>
>>>> Okay, if we use this approach then I think the default should ensure a=
t
>>>> least one screenful is considered, so maybe 10000.
>>>>
>>>
--0000000000001e376106583829c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Mon, Aug 3, 2026 at 5:37=E2=80=AFAM Jo=C3=A3o T=C3=A1vora <<a hre=
f=3D"mailto:joaotavora@HIDDEN">joaotavora@HIDDEN</a>> wrote:</span=
></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto"><div>Did someone test th=
e candidate code with SLY's current e-p-m and comint integration? Is th=
ere any reason to think it might break? I hope not.=C2=A0</div></div></bloc=
kquote><div><br></div><div>I think as long as SLY doesn't use fields in=
some strange way, it should be OK.=C2=A0 I haven't tested with SLY but=
if you let me know what e-p-m is and how to test it, I can test it out.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">If SLY decides t=
o migrate to the new style of comint integration (presuming there is one, a=
t least that's where I saw the discussion headed) is there a manual or =
example to follow?</div></div></blockquote><div><br></div><div>I don't =
think there's anything SLY would need to do, as long as it is using com=
int in the normal way, which automatically uses different fields for non-us=
er input and prompts, and user-inputs are not in a field at all.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"a=
uto"><div><br></div><div>Jo=C3=A3o</div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 3, 2026, 02:35 Andrew H=
yatt <<a href=3D"mailto:ahyatt@HIDDEN" target=3D"_blank">ahyatt@gmail=
.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><p>
Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" rel=3D"noreferrer" target=
=3D"_blank">eliz@HIDDEN</a>> writes:
</p>
<p>
</p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Ping! Any further comments or suggestions?
</div></blockquote>
<p></p>
<p>
In case there is not, I'm attaching a patch for the complete change, no=
w
including a mention of the behavior in the manual, and two new tests.
</p>
<p>
</p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<div>From: Andrew Hyatt <<a href=3D"mailto:ahyatt@HIDDEN" rel=3D"nore=
ferrer" target=3D"_blank">ahyatt@HIDDEN</a>>
Cc: Ihor Radchenko <<a href=3D"mailto:yantar92@HIDDEN" rel=3D"norefe=
rrer" target=3D"_blank">yantar92@HIDDEN</a>>, Lars Ingebrigtsen
<<a href=3D"mailto:larsi@HIDDEN" rel=3D"noreferrer" target=3D"_blank">=
larsi@HIDDEN</a>>, <a href=3D"mailto:50236 <at> debbugs.gnu.org" rel=3D"no=
referrer" target=3D"_blank">50236 <at> debbugs.gnu.org</a>, <a href=3D"mailto:j=
oaotavora@HIDDEN" rel=3D"noreferrer" target=3D"_blank">joaotavora@gmail.=
com</a>,
<a href=3D"mailto:eliz@HIDDEN" rel=3D"noreferrer" target=3D"_blank">eliz@g=
nu.org</a>
Date: Sun, 19 Jul 2026 17:28:18 -0400
</div>
<div>
<br></div>
<div>Augusto Stoffel <<a href=3D"mailto:arstoffel@HIDDEN" rel=3D"nore=
ferrer" target=3D"_blank">arstoffel@HIDDEN</a>> writes:=20
</div>
<div>
<br></div>
<div>Hi Andrew,=20
</div>
<div>
<br></div>
<div>in your proposed patch, why did you choose to change electric-pair-pos=
t-self-insert-function directly and
not electric-pair-default-skip-self (or even define a skip-self function sp=
ecifically for comint)?=20
</div>
<div>
<br></div>
<div>Isn't skip-self for avoiding two closing parens in a row? This doe=
sn't seem related to the problem.=20
</div>
<div>
<br></div>
<div>Also, I should mention over another solution that Jo=C3=A3o had previo=
usly implemented for Sly, discussed on the
bug I merged into this one, this issue can be partially solved on `comint` =
or other mode side by marking the
non-user generated text with a comment syntax, which electric-pair already =
skips. That solves the issue that
program output in comint can mess up balance, but not that two separate inp=
uts should have independent
balance.=20
</div>
<div>
<br></div>
<div>Maybe that's okay, but then it would force other modes to solve si=
milar issues by using field properties.=20
</div>
<div>
<br></div>
<div>I think that's probably a good idea; using fields to represent dif=
ferent provenance of input is a good general
practice that electric-pair and perhaps other modes may come to rely on.=20
</div>
<div>
<br></div>
<div>I've added Ihor to the discussion since the issue affects Org mode=
as well (see my email of 22 Aug 2022
in this thread). WDYT?=20
</div>
<div>
<br></div>
<div>On Sat, 18 Jul 2026, Andrew Hyatt wrote:=20
</div>
<div>
<br></div>
<div>Augusto Stoffel <<a href=3D"mailto:arstoffel@HIDDEN" rel=3D"nore=
ferrer" target=3D"_blank">arstoffel@HIDDEN</a>> writes:=20
</div>
<div>
<br></div>
<div>Is the search bound (and attending local variable) really necessary? T=
ext property search uses an
interval tree so it's better than linear time in the character counts.=
=20
</div>
<div>
<br></div>
<div>I was able to construct a buffer that, without the bound, took tens of=
milliseconds to get the previous
field. Basically, lots of different faces, etc, which requires a lot of ite=
ration. I'm not sure what the
normal expectations are, but I thought it best to err on the side of making=
sure everything stays
optimally fast.=20
</div>
<div>
<br></div>
<div>The 1000 char limit is more than enough for normal comint use, in my e=
xperience.=20
</div>
<div>
<br></div>
<div>Okay, if we use this approach then I think the default should ensure a=
t least one screenful is considered,
so maybe 10000.=20
</div></blockquote>
</div></blockquote>
<p></p>
</blockquote></div>
</blockquote></div></div>
--0000000000001e376106583829c8--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 3 Aug 2026 09:37:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 03 05:37:10 2026 Received: from localhost ([127.0.0.1]:53603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wqp6c-00049X-1e for submit <at> debbugs.gnu.org; Mon, 03 Aug 2026 05:37:10 -0400 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]:51607) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1wqp6Y-000494-MZ for 50236 <at> debbugs.gnu.org; Mon, 03 Aug 2026 05:37:08 -0400 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-7ee37dc91f5so1910388a34.3 for <50236 <at> debbugs.gnu.org>; Mon, 03 Aug 2026 02:37:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785749821; cv=none; d=google.com; s=arc-20260327; b=YC6JUi7z7ydR5+qt3YZfL5l8PukNKs1S2MJqSxGNgcvsSDZofRCxQoZui1af16lVs+ Eurw75eCCD6mDawUeOcXcDAjoGemcVEgHRYpKoUxHxX1qW0GOb8k6hxwzcXx5XINOcaP QA5EsLveIefRfjb7gI6NuFUnVdGch7ULFKHh3o/EnA6k451blIPfVDDv18OXunyW4lGL Vzatja6egjgO8FN0idV+4jK+rC3AhJhUxh4TD9Ct2+uIhq0/3smQsnD0WXQLZr/3ZVpv B7XxoAQtRtKXM/jGlgGf2KlFU/yTIKowiA23czITNNQ0vK4ESSVU3h4jiRH3u6+50GPo yG+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=mVuoSenzGNBTxmMnDzHrWstlb4Mw82IeEF4Nn1UgKNs=; fh=1Jbrf8+i5ZeqsUAObHOvPTqr1JntKWX7Y8V8q+9CsJE=; b=IsWVMxdU1lo4jrISWfSw3rJjIoQxdjCsKAp4tRLgd8BJ9gjvj1AwAvuhRCPyHVkGH2 nmKi4o6jfpJ82ReYyEe2QdaYgMYqJxtdF3QGzSB74UJG6GawKGECsBN0NPSetDZggXiN UbNR1Pxmsam6f1nFA1ciduGQAotvAggRAQeN+lr4xE7neDMP7PK42iPEPqHsrxA6c9Ml A/Cd6PfI6ri8mUsoCoB6Ol0h+nAd5H+0OL31JdgPKdHDkTSit+7a4LhGz/xSmh30u1mT J6GdSh7gYtjY/pKJxlyepK8PU1yfALusQ3bpMYqeUCsW6SUN1o8wpDlnJx4KGND5wESD dw1g==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785749821; x=1786354621; darn=debbugs.gnu.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mVuoSenzGNBTxmMnDzHrWstlb4Mw82IeEF4Nn1UgKNs=; b=IWy8zqmaBbZhVNq3WcwP5NCAz5vjWi2J+Oi2fP4eIWTzWzGgD0I93rJM96LzDi5wGt VmKGe1Ge6McxRA01k4rnSqD3d9PDvCWcQIE+CFOt6v3WjLOAfcehVT9d/2It2XJAM2AJ Vvp3uTKvwjTiY98k7P5ibSZfSC3jeb1SJyxnjz6rgXJvsSVb2C8DkQvnWojtvW+FbJK/ gSCI3eHRSlb7YiSifumrxy2Xvz1+Eb2QJ5SJDAZbcKh6BgMX8UttIYhH3ZBB658aHFXW a7z9MprgBdL73oNiWl+stfLNEl+YGXXgypVFoeavNBMHhTo3hrkuOrwb3YbOyr+yxh+T 3LRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785749821; x=1786354621; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=mVuoSenzGNBTxmMnDzHrWstlb4Mw82IeEF4Nn1UgKNs=; b=EImGg5xxGLM7MoVmROx/CAuINVjwjHfXiphpIpYzh6zHgV2JfH5EHnAt5Ae08LVa1J tIit6zxQRrPLRsmdjPfPJKvGFYJjswBoj8xm7kcClvBqMLTicpxphUIxmVSlp2hsQYDs 8nHKo3mTWMUvZBdYCxxPqqsf+Al0fEDJBcbQHVYhNZx/AxXTdecnq+WEv7wuzBryJg6K jzbZy4dC4XFU0dv9vjEHnu4N1bXdY33sjMr1EaEJzFLyOXozOMmrMhu+DtcyVUtCckY8 VC71uVkgFYHphTeAemA4/C8ie1w/fNfL4RiG1iXtRIy+SXbe6KkshvFUOOt/lM6SCLbG RoKQ== X-Forwarded-Encrypted: i=1; AHgh+RqNjrBuomQz3s9ETDWBq1h4TcIeSukAAJusX2GWbI1f5Bk1CjqW1MNj2GIMZ5NCw8uRVOKN7A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyvCZ77GOu51b2+GhpzacM3efsx9TIHzJHgCCzwHE/YhFdRYc/i VtlPaRWgLxMQ7/8zLQyT3BgrhWepYU7rr3q4N7elo/1/tbucHWQzNmDEZW6WBzSZVmvLKLWSDmA ncdTCTf/yxG41lQVtw9UNkUyaxTQJ7Ig= X-Gm-Gg: AR+sD121ZhtGsNDgFQQ7ivlrvsnRafBiqxw/HqrZBAZKqbm/ucNzhcU6UVDKIKfzKQu nIBGfZ7xToWqVWugTsWo4TozFQlmc78zf8yiMJ3QQEL81yFKbhqkGlAqfp4je83uDFzcCzkpxk9 nT0OADADrOUWeu4u0gI7l2jqEi0eacc9C1UBXFuSiSIt7eXtdWu4LT1zEXCwxEttyBYdn50jud3 wNBR4imERQX7+ZqaYjjVq4mku3viakCuruEKowaKtmKYyV0J9QQzIPfOvWFMLxXfgpOuXJkuG8X /RM84UtU5QAJVFshvIZfFu9jhB+Op4+2ZP7zaTwJYaJuwRQlqK98r74yIwXYthKJ9wAsq2FQo3D 8F++Rqd3EQZ/4j2HlqWTbseVLEL3Y X-Received: by 2002:a05:6808:50a7:b0:495:feaa:9e3b with SMTP id 5614622812f47-4af5e08a49fmr16041576b6e.7.1785749820707; Mon, 03 Aug 2026 02:37:00 -0700 (PDT) MIME-Version: 1.0 References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> <87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN> <87wlur4cjr.fsf@HIDDEN> <m25x2aacul.fsf@HIDDEN> <86cxw2i5s7.fsf@HIDDEN> <m2o6fk6l6n.fsf@HIDDEN> In-Reply-To: <m2o6fk6l6n.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 3 Aug 2026 10:36:49 +0100 X-Gm-Features: AUfX_mygH8Ja2I-inXwMisYglbXAG72xjZlcnLBsfb-EVGEOTdFRWaWFtKA8F6g Message-ID: <CALDnm51D8vExcstbKEGPNdxgtpMQXc_eNg8MqMDiu+Xo9caLqg@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint To: Andrew Hyatt <ahyatt@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000b897470658214765" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 50236 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 50236 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000b897470658214765 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Did someone test the candidate code with SLY's current e-p-m and comint integration? Is there any reason to think it might break? I hope not. If SLY decides to migrate to the new style of comint integration (presuming there is one, at least that's where I saw the discussion headed) is there a manual or example to follow? Jo=C3=A3o On Mon, Aug 3, 2026, 02:35 Andrew Hyatt <ahyatt@HIDDEN> wrote: > Eli Zaretskii <eliz@HIDDEN> writes: > > Ping! Any further comments or suggestions? >> > In case there is not, I'm attaching a patch for the complete change, now > including a mention of the behavior in the manual, and two new tests. > > From: Andrew Hyatt <ahyatt@HIDDEN> Cc: Ihor Radchenko < >>> yantar92@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, >>> 50236 <at> debbugs.gnu.org, joaotavora@HIDDEN, eliz@HIDDEN Date: Sun, 19 >>> Jul 2026 17:28:18 -0400 >>> >>> Augusto Stoffel <arstoffel@HIDDEN> writes: >>> >>> Hi Andrew, >>> >>> in your proposed patch, why did you choose to change >>> electric-pair-post-self-insert-function directly and not >>> electric-pair-default-skip-self (or even define a skip-self function >>> specifically for comint)? >>> >>> Isn't skip-self for avoiding two closing parens in a row? This doesn't >>> seem related to the problem. >>> >>> Also, I should mention over another solution that Jo=C3=A3o had previou= sly >>> implemented for Sly, discussed on the bug I merged into this one, this >>> issue can be partially solved on `comint` or other mode side by marking= the >>> non-user generated text with a comment syntax, which electric-pair alre= ady >>> skips. That solves the issue that program output in comint can mess up >>> balance, but not that two separate inputs should have independent balan= ce. >>> >>> Maybe that's okay, but then it would force other modes to solve similar >>> issues by using field properties. >>> >>> I think that's probably a good idea; using fields to represent differen= t >>> provenance of input is a good general practice that electric-pair and >>> perhaps other modes may come to rely on. >>> >>> I've added Ihor to the discussion since the issue affects Org mode as >>> well (see my email of 22 Aug 2022 in this thread). WDYT? >>> >>> On Sat, 18 Jul 2026, Andrew Hyatt wrote: >>> >>> Augusto Stoffel <arstoffel@HIDDEN> writes: >>> >>> Is the search bound (and attending local variable) really necessary? >>> Text property search uses an interval tree so it's better than linear t= ime >>> in the character counts. >>> >>> I was able to construct a buffer that, without the bound, took tens of >>> milliseconds to get the previous field. Basically, lots of different fa= ces, >>> etc, which requires a lot of iteration. I'm not sure what the normal >>> expectations are, but I thought it best to err on the side of making su= re >>> everything stays optimally fast. >>> >>> The 1000 char limit is more than enough for normal comint use, in my >>> experience. >>> >>> Okay, if we use this approach then I think the default should ensure at >>> least one screenful is considered, so maybe 10000. >>> >> --000000000000b897470658214765 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Did someone test the candidate code with SLY's c= urrent e-p-m and comint integration? Is there any reason to think it might = break? I hope not.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"= >If SLY decides to migrate to the new style of comint integration (presumin= g there is one, at least that's where I saw the discussion headed) is t= here a manual or example to follow?</div><div><br></div><div data-smartmail= =3D"gmail_signature">Jo=C3=A3o</div></div><br><div class=3D"gmail_quote gma= il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 3, 20= 26, 02:35 Andrew Hyatt <<a href=3D"mailto:ahyatt@HIDDEN">ahyatt@gmail= .com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex"><p> Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank" rel=3D"= noreferrer">eliz@HIDDEN</a>> writes: </p> <p> </p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> <div>Ping! Any further comments or suggestions? </div></blockquote> <p></p> <p> In case there is not, I'm attaching a patch for the complete change, no= w including a mention of the behavior in the manual, and two new tests. </p> <p> </p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <div>From: Andrew Hyatt <<a href=3D"mailto:ahyatt@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">ahyatt@HIDDEN</a>> Cc: Ihor Radchenko <<a href=3D"mailto:yantar92@HIDDEN" target=3D"_bl= ank" rel=3D"noreferrer">yantar92@HIDDEN</a>>, Lars Ingebrigtsen <<a href=3D"mailto:larsi@HIDDEN" target=3D"_blank" rel=3D"noreferrer">= larsi@HIDDEN</a>>, <a href=3D"mailto:50236 <at> debbugs.gnu.org" target=3D= "_blank" rel=3D"noreferrer">50236 <at> debbugs.gnu.org</a>, <a href=3D"mailto:j= oaotavora@HIDDEN" target=3D"_blank" rel=3D"noreferrer">joaotavora@gmail.= com</a>, <a href=3D"mailto:eliz@HIDDEN" target=3D"_blank" rel=3D"noreferrer">eliz@g= nu.org</a> Date: Sun, 19 Jul 2026 17:28:18 -0400 </div> <div> <br></div> <div>Augusto Stoffel <<a href=3D"mailto:arstoffel@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">arstoffel@HIDDEN</a>> writes:=20 </div> <div> <br></div> <div>Hi Andrew,=20 </div> <div> <br></div> <div>in your proposed patch, why did you choose to change electric-pair-pos= t-self-insert-function directly and not electric-pair-default-skip-self (or even define a skip-self function sp= ecifically for comint)?=20 </div> <div> <br></div> <div>Isn't skip-self for avoiding two closing parens in a row? This doe= sn't seem related to the problem.=20 </div> <div> <br></div> <div>Also, I should mention over another solution that Jo=C3=A3o had previo= usly implemented for Sly, discussed on the bug I merged into this one, this issue can be partially solved on `comint` = or other mode side by marking the non-user generated text with a comment syntax, which electric-pair already = skips. That solves the issue that program output in comint can mess up balance, but not that two separate inp= uts should have independent balance.=20 </div> <div> <br></div> <div>Maybe that's okay, but then it would force other modes to solve si= milar issues by using field properties.=20 </div> <div> <br></div> <div>I think that's probably a good idea; using fields to represent dif= ferent provenance of input is a good general practice that electric-pair and perhaps other modes may come to rely on.=20 </div> <div> <br></div> <div>I've added Ihor to the discussion since the issue affects Org mode= as well (see my email of 22 Aug 2022 in this thread). WDYT?=20 </div> <div> <br></div> <div>On Sat, 18 Jul 2026, Andrew Hyatt wrote:=20 </div> <div> <br></div> <div>Augusto Stoffel <<a href=3D"mailto:arstoffel@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">arstoffel@HIDDEN</a>> writes:=20 </div> <div> <br></div> <div>Is the search bound (and attending local variable) really necessary? T= ext property search uses an interval tree so it's better than linear time in the character counts.= =20 </div> <div> <br></div> <div>I was able to construct a buffer that, without the bound, took tens of= milliseconds to get the previous field. Basically, lots of different faces, etc, which requires a lot of ite= ration. I'm not sure what the normal expectations are, but I thought it best to err on the side of making= sure everything stays optimally fast.=20 </div> <div> <br></div> <div>The 1000 char limit is more than enough for normal comint use, in my e= xperience.=20 </div> <div> <br></div> <div>Okay, if we use this approach then I think the default should ensure a= t least one screenful is considered, so maybe 10000.=20 </div></blockquote> </div></blockquote> <p></p> </blockquote></div> --000000000000b897470658214765--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
Received: (at 50236) by debbugs.gnu.org; 3 Aug 2026 01:35:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 02 21:35:22 2026
Received: from localhost ([127.0.0.1]:50060 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wqhaA-0001qA-Pp
for submit <at> debbugs.gnu.org; Sun, 02 Aug 2026 21:35:21 -0400
Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]:50442)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <ahyatt@HIDDEN>) id 1wqha5-0001l5-BL
for 50236 <at> debbugs.gnu.org; Sun, 02 Aug 2026 21:35:08 -0400
Received: by mail-qt1-x832.google.com with SMTP id
d75a77b69052e-51c0006ea8eso19368431cf.1
for <50236 <at> debbugs.gnu.org>; Sun, 02 Aug 2026 18:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1785720900; x=1786325700; 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=pSR4ouWLuZGKm6vZ/HxJN4Up0HK9n6MG113S4d5Uuqc=;
b=flnFmaRn/y9PZZextA7GDkIrAXqU+hsfzgV6OfImstVrdPC5Fhko52Co/RP8N5oxht
Vaf4zCBlqQYmTd4bxPvXXDmzzpV6qXJlf0eki1TW9bGKWw9yK4qW5v+hQOIQ4DPkOe4X
Scl8C+6lZq0Dgv7gTPo44wpWk1Tj2tVEsfC9EQ5wfQsFxU+GAr9sbJQqaQb0VPk/ODro
D4CK37Iuh12EMaVzWxrHTMiVgsQeQVkpE3Tojz4CzSesBQ7KWreKx7ZgCuJX0V4tsSJO
ntwBtibkivk8FBecRgujwKSJlEgVvrpR6Caxd5dNcbvc07s5+yDJP4LGFwJMmCmoLms6
/5OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1785720900; x=1786325700;
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=pSR4ouWLuZGKm6vZ/HxJN4Up0HK9n6MG113S4d5Uuqc=;
b=akM3dZPpmBA1pKuz2bLsNVmqtAjNy4Z3lB8Iafg+tJYrIYHVVUT1QvPmCTWf2tXfVu
p9KIbNy3l9vsgyBTkzwkAUVSIS66EfRQSxEVYr6O81QsbatYZTijcr3TngOn7D5/kDyA
xo1502W3/oGSDUdTYZ6ezVaeULnBavU80FH6YPa7ceDjbWcnfI2voEHTbOWNhKfGAhSR
aDYMRxjdVjYRsTcJlc8IUVg5TQYiKtdhF8hL8fqLXLLATJ+nX8E/qvTdYQSCsNOSLxHZ
q6vjGwaPJT/g5JuZaKT+YPv+v127y+aO0tQW15tW7HFGvzV6h5OXTqvSYA+f8jSiybKM
rzBw==
X-Forwarded-Encrypted: i=1;
AHgh+RrjpXv2k3mh4DMGHKIOCSsmF2HP0NKuFTb4+TByxVNqft4rtJBcZYV2YlhHgBUoS7Qm7LCs6A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YworQnAzSbk0kF7H2tXhySmmi5T7qiOy5ITOgSFbqk20dbJTggG
FY+FF1J026+4PlwkE6y18txVPWDSryK/7+ac4SiPIoNhaX348QxDZk7B
X-Gm-Gg: AR+sD11R39DDduR6K44If4TTSnIqnyk0jdZUWVzwvrtG+eklRzoN1m9Ai3qWrQpikcP
C3najr0snZv9gJGzewz7PH2SEfX6+Ki4rqCUphg5Ku1V/v7ZEduLDXXrK7dSlU58bnG78L6sZfA
m+V9bvecT3iDxNlJBLPhYBhhcXVWwipVq1gx/tuylYiZ/HFXMDmoV9iY/tWyPsYhgTpsk6OBTQg
GAhCJuq4ioHMpr8jT1wLAnDmgM0NAd2zoFdmM3RtDKL1mhjfXboIi7VR+EhtntkqEGfe3Hrh5+C
5iiRSB89qr24DjJX5GiFNrwGOpohkPDnMmZZD3ouptR1g5RqxoAK9U6KLelGX+BBaLkZZR86JlR
hO/i7OuWAHNueTY+vGuNgRwmUfpRcbQ4fEUElJW2yLrEwDxGVQFv5tOhWNpugMfd1XqFNIwJkjz
CUM1YfFghBeqQE0m+LcVbC067oKs/vqJ9CrG6ih645ekoPNA27jytLJOt7advi2QqWzTyoXkduJ
p1hV/3SK7PCcc465/kTdIuk2wvd84GU2m+eE2wzW1CIW8A+dmgwnTdQzOcUuzW9rYClC7uQc1/Y
hQnkCDa/GAQQF3pTTtjLb9Q9Z/jUsxldgCdhicCP7MUkB90hFHk=
X-Received: by 2002:a05:622a:103:b0:51a:6feb:dc8a with SMTP id
d75a77b69052e-52b566ae942mr161807591cf.18.1785720899549;
Sun, 02 Aug 2026 18:34:59 -0700 (PDT)
Received: from ahyatt-home.local ([2600:4041:5d2d:5d00:950:825a:dae3:39d0])
by smtp.gmail.com with ESMTPSA id
d75a77b69052e-52b4eb96ad0sm51433291cf.23.2026.08.02.18.34.56
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 02 Aug 2026 18:34:57 -0700 (PDT)
From: Andrew Hyatt <ahyatt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint
In-Reply-To: <86cxw2i5s7.fsf@HIDDEN>
References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN>
<87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN>
<875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN>
<87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN>
<87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN>
<87wlur4cjr.fsf@HIDDEN> <m25x2aacul.fsf@HIDDEN>
<86cxw2i5s7.fsf@HIDDEN>
Date: Sun, 02 Aug 2026 21:34:56 -0400
Message-ID: <m2o6fk6l6n.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: > Ping! Any further comments or
suggestions?
In case there is not, I'm attaching a patch for the complete change, now
including a mention of the behavior in the manual, and two new tests.
Content analysis details: (2.0 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2607:f8b0:4864:20:0:0:0:832 listed in]
[list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (ahyatt[at]gmail.com)
0.0 HTML_MESSAGE BODY: HTML included in message
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Debbugs-Envelope-To: 50236
Cc: yantar92@HIDDEN, 50236 <at> debbugs.gnu.org, arstoffel@HIDDEN,
larsi@HIDDEN, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--=-=-=
Content-Type: multipart/alternative; boundary="==-=-="
--==-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@HIDDEN> writes:
> Ping! Any further comments or suggestions?
In case there is not, I'm attaching a patch for the complete change, now
including a mention of the behavior in the manual, and two new tests.
>
>> From: Andrew Hyatt <ahyatt@HIDDEN>
>> Cc: Ihor Radchenko <yantar92@HIDDEN>, Lars Ingebrigtsen
>> <larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, joaotavora@HIDDEN,
>> eliz@HIDDEN
>> Date: Sun, 19 Jul 2026 17:28:18 -0400
>>=20
>> Augusto Stoffel <arstoffel@HIDDEN> writes:=20
>>=20
>> Hi Andrew,=20
>>=20
>> in your proposed patch, why did you choose to change electric-pair-post=
-self-insert-function directly and
>> not electric-pair-default-skip-self (or even define a skip-self functio=
n specifically for comint)?=20
>>=20
>> Isn't skip-self for avoiding two closing parens in a row? This doesn't s=
eem related to the problem.=20
>>=20
>> Also, I should mention over another solution that Jo=C3=A3o had previous=
ly implemented for Sly, discussed on the
>> bug I merged into this one, this issue can be partially solved on `comin=
t` or other mode side by marking the
>> non-user generated text with a comment syntax, which electric-pair alrea=
dy skips. That solves the issue that
>> program output in comint can mess up balance, but not that two separate =
inputs should have independent
>> balance.=20
>>=20
>> Maybe that's okay, but then it would force other modes to solve similar=
issues by using field properties.=20
>>=20
>> I think that's probably a good idea; using fields to represent different=
provenance of input is a good general
>> practice that electric-pair and perhaps other modes may come to rely on.=
=20
>>=20
>> I've added Ihor to the discussion since the issue affects Org mode as w=
ell (see my email of 22 Aug 2022
>> in this thread). WDYT?=20
>>=20
>> On Sat, 18 Jul 2026, Andrew Hyatt wrote:=20
>>=20
>> Augusto Stoffel <arstoffel@HIDDEN> writes:=20
>>=20
>> Is the search bound (and attending local variable) really necessary? Te=
xt property search uses an
>> interval tree so it's better than linear time in the character counts.=
=20
>>=20
>> I was able to construct a buffer that, without the bound, took tens of =
milliseconds to get the previous
>> field. Basically, lots of different faces, etc, which requires a lot of=
iteration. I'm not sure what the
>> normal expectations are, but I thought it best to err on the side of ma=
king sure everything stays
>> optimally fast.=20
>>=20
>> The 1000 char limit is more than enough for normal comint use, in my ex=
perience.=20
>>=20
>> Okay, if we use this approach then I think the default should ensure at=
least one screenful is considered,
>> so maybe 10000.=20
--==-=-=
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<p>
Eli Zaretskii <eliz@HIDDEN> writes:
</p>
<p>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>Ping! Any further comments or suggestions?
</div></blockquote>
</p>
<p>
In case there is not, I'm attaching a patch for the complete change, now
including a mention of the behavior in the manual, and two new tests.
</p>
<p>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>From: Andrew Hyatt <ahyatt@HIDDEN>
Cc: Ihor Radchenko <yantar92@HIDDEN>, Lars Ingebrigtsen
<larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, joaotavora@HIDDEN,
eliz@HIDDEN
Date: Sun, 19 Jul 2026 17:28:18 -0400
</div>
<div>
<br /></div>
<div>Augusto Stoffel <arstoffel@HIDDEN> writes:=20
</div>
<div>
<br /></div>
<div>Hi Andrew,=20
</div>
<div>
<br /></div>
<div>in your proposed patch, why did you choose to change electric-pair-pos=
t-self-insert-function directly and
not electric-pair-default-skip-self (or even define a skip-self function sp=
ecifically for comint)?=20
</div>
<div>
<br /></div>
<div>Isn't skip-self for avoiding two closing parens in a row? This doesn't=
seem related to the problem.=20
</div>
<div>
<br /></div>
<div>Also, I should mention over another solution that Jo=C3=A3o had previo=
usly implemented for Sly, discussed on the
bug I merged into this one, this issue can be partially solved on `comint` =
or other mode side by marking the
non-user generated text with a comment syntax, which electric-pair already =
skips. That solves the issue that
program output in comint can mess up balance, but not that two separate inp=
uts should have independent
balance.=20
</div>
<div>
<br /></div>
<div>Maybe that's okay, but then it would force other modes to solve simila=
r issues by using field properties.=20
</div>
<div>
<br /></div>
<div>I think that's probably a good idea; using fields to represent differe=
nt provenance of input is a good general
practice that electric-pair and perhaps other modes may come to rely on.=20
</div>
<div>
<br /></div>
<div>I've added Ihor to the discussion since the issue affects Org mode as =
well (see my email of 22 Aug 2022
in this thread). WDYT?=20
</div>
<div>
<br /></div>
<div>On Sat, 18 Jul 2026, Andrew Hyatt wrote:=20
</div>
<div>
<br /></div>
<div>Augusto Stoffel <arstoffel@HIDDEN> writes:=20
</div>
<div>
<br /></div>
<div>Is the search bound (and attending local variable) really necessary? T=
ext property search uses an
interval tree so it's better than linear time in the character counts.=20
</div>
<div>
<br /></div>
<div>I was able to construct a buffer that, without the bound, took tens of=
milliseconds to get the previous
field. Basically, lots of different faces, etc, which requires a lot of ite=
ration. I'm not sure what the
normal expectations are, but I thought it best to err on the side of making=
sure everything stays
optimally fast.=20
</div>
<div>
<br /></div>
<div>The 1000 char limit is more than enough for normal comint use, in my e=
xperience.=20
</div>
<div>
<br /></div>
<div>Okay, if we use this approach then I think the default should ensure a=
t least one screenful is considered,
so maybe 10000.=20
</div></blockquote>
</div></blockquote>
</p>
--==-=-=--
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=0001-electric-pair-fix-v2.patch
Content-Description: Complete patch for electric-pair fix
diff --git a/doc/emacs/programs.texi b/doc/emacs/programs.texi
index 7cf7b2ff96f..9be597eea29 100644
--- a/doc/emacs/programs.texi
+++ b/doc/emacs/programs.texi
@@ -1129,7 +1129,9 @@ Matching
buffer. And typing a closing delimiter immediately before another
closing delimiter of the same type does not insert that character but
moves point as described above, even when there is an unpaired matching
-opening delimiter earlier in the buffer.
+opening delimiter earlier in the buffer. Matching does not consider the
+whole buffer, only the current field, so for example, previous input or
+non-user input in comint buffers is not included.
If there is an active region, this variable has no effect.
diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
index 54fbc960b0f..5f338f686f5 100644
--- a/lisp/elec-pair.el
+++ b/lisp/elec-pair.el
@@ -228,6 +228,16 @@ electric-pair-skip-whitespace-chars
(const :tag "Newline" ?\n))
(repeat (character :value " "))))
+(defvar-local electric-pair-max-field-size 1000
+ "Maximum number of characters to search for a field boundary.
+
+This is used to limit how far we search the buffer to find a field
+boundary to restrict the search for matching pairs to. If there is no
+field boundary within this many characters, then we will not attempt to
+restrict the matching, otherwise we only match within the field.
+
+This is buffer local because different modes may want to tweak this.")
+
(defvar-local electric-pair-skip-whitespace-function
#'electric-pair--skip-whitespace
"Function to use to move point forward over whitespace.
@@ -620,88 +630,100 @@ electric-pair-post-self-insert-function
(both as defined by the major mode's syntax table). This is
done by looking up the variables
`electric-pair-inhibit-predicate', `electric-pair-skip-self'
- and `electric-pair-skip-whitespace' (which see)."
- (let* ((pos (and electric-pair-mode (electric--after-char-pos)))
- (num (when pos (prefix-numeric-value current-prefix-arg)))
- (beg (when num (- pos num)))
- (skip-whitespace-info))
- (pcase (electric-pair-syntax-info last-command-event)
- (`(,syntax ,pair ,unconditional ,space)
- (cond
- ((null pos) nil)
- ((zerop num) nil)
- ;; Wrap a pair around the active region.
- ;;
- ((and (memq syntax '(?\( ?\) ?\" ?\$)) (use-region-p))
- ;; FIXME: To do this right, we'd need a post-self-insert-function
- ;; so we could add-function around it and insert the closer after
- ;; all the rest of the hook has run.
- (if (or (eq syntax ?\")
- (and (eq syntax ?\))
- (>= (point) (mark)))
- (and (not (eq syntax ?\)))
- (>= (mark) (point))))
- (save-excursion
- (goto-char (mark))
- (electric-pair--insert pair num))
- (delete-region beg pos)
- (electric-pair--insert pair num)
- (goto-char (mark))
- (electric-pair--insert last-command-event num)))
- ;; Backslash-escaped: no pairing, no skipping.
- ((save-excursion
- (goto-char beg)
- (not (evenp (skip-syntax-backward "\\"))))
- (let ((current-prefix-arg (1- num)))
- (electric-pair-post-self-insert-function)))
- ;; Skip self.
- ((and (memq syntax '(?\) ?\" ?\$))
- (and (or unconditional
- (if (functionp electric-pair-skip-self)
- (electric-pair--save-literal-point-excursion
- (goto-char pos)
- (funcall electric-pair-skip-self
- last-command-event))
- electric-pair-skip-self))
- (save-excursion
- (when (and
- (not (and unconditional (eq syntax ?\")))
- (setq skip-whitespace-info
- (if (and
- (not
- (eq electric-pair-skip-whitespace
- 'chomp))
- (functionp electric-pair-skip-whitespace))
- (funcall electric-pair-skip-whitespace)
- electric-pair-skip-whitespace)))
- (funcall electric-pair-skip-whitespace-function))
- (eq (char-after) last-command-event))))
- ;; This is too late: rather than insert&delete we'd want to only
- ;; skip (or insert in overwrite mode). The difference is in what
- ;; goes in the undo-log and in the intermediate state which might
- ;; be visible to other post-self-insert-hook. We'll just have to
- ;; live with it for now.
- (when skip-whitespace-info
- (funcall electric-pair-skip-whitespace-function))
- (delete-region beg (if (eq skip-whitespace-info 'chomp)
- (point)
- pos))
- (forward-char num))
- ;; Insert matching pair.
- ;; String pairs
- ((and (eq syntax 'str) (not overwrite-mode))
- (if space (insert " "))
- (save-excursion
- (insert pair)))
- ;; Char pairs
- ((and (memq syntax '(?\( ?\" ?\$))
- (not overwrite-mode)
- (or unconditional
- (not (electric-pair--save-literal-point-excursion
- (goto-char pos)
- (funcall electric-pair-inhibit-predicate
- last-command-event)))))
- (save-excursion (electric-pair--insert pair num))))))))
+ and `electric-pair-skip-whitespace' (which see).
+
+If possible, this function will attempt to match delimiters for the
+current field only. However, we limit how much we scan for the
+beginning and end of the field to limit possible computation, so in
+large fields this falls back to using the entire buffer for matching."
+ (with-restriction
+ (let* ((subtracted-point (- (point) electric-pair-max-field-size))
+ (beginning (field-beginning nil nil (max (point-min) subtracted-point))))
+ (if (or (use-region-p) (= beginning subtracted-point)) (point-min) beginning))
+ (let* ((added-point (+ (point) electric-pair-max-field-size))
+ (end (field-end nil nil (min (point-max) added-point))))
+ (if (or (use-region-p) (= end added-point)) (point-max) end))
+ (let* ((pos (and electric-pair-mode (electric--after-char-pos)))
+ (num (when pos (prefix-numeric-value current-prefix-arg)))
+ (beg (when num (- pos num)))
+ (skip-whitespace-info))
+ (pcase (electric-pair-syntax-info last-command-event)
+ (`(,syntax ,pair ,unconditional ,space)
+ (cond
+ ((null pos) nil)
+ ((zerop num) nil)
+ ;; Wrap a pair around the active region.
+ ;;
+ ((and (memq syntax '(?\( ?\) ?\" ?\$)) (use-region-p))
+ ;; FIXME: To do this right, we'd need a post-self-insert-function
+ ;; so we could add-function around it and insert the closer after
+ ;; all the rest of the hook has run.
+ (if (or (eq syntax ?\")
+ (and (eq syntax ?\))
+ (>= (point) (mark)))
+ (and (not (eq syntax ?\)))
+ (>= (mark) (point))))
+ (save-excursion
+ (goto-char (mark))
+ (electric-pair--insert pair num))
+ (delete-region beg pos)
+ (electric-pair--insert pair num)
+ (goto-char (mark))
+ (electric-pair--insert last-command-event num)))
+ ;; Backslash-escaped: no pairing, no skipping.
+ ((save-excursion
+ (goto-char beg)
+ (not (evenp (skip-syntax-backward "\\"))))
+ (let ((current-prefix-arg (1- num)))
+ (electric-pair-post-self-insert-function)))
+ ;; Skip self.
+ ((and (memq syntax '(?\) ?\" ?\$))
+ (and (or unconditional
+ (if (functionp electric-pair-skip-self)
+ (electric-pair--save-literal-point-excursion
+ (goto-char pos)
+ (funcall electric-pair-skip-self
+ last-command-event))
+ electric-pair-skip-self))
+ (save-excursion
+ (when (and
+ (not (and unconditional (eq syntax ?\")))
+ (setq skip-whitespace-info
+ (if (and
+ (not
+ (eq electric-pair-skip-whitespace
+ 'chomp))
+ (functionp electric-pair-skip-whitespace))
+ (funcall electric-pair-skip-whitespace)
+ electric-pair-skip-whitespace)))
+ (funcall electric-pair-skip-whitespace-function))
+ (eq (char-after) last-command-event))))
+ ;; This is too late: rather than insert&delete we'd want to only
+ ;; skip (or insert in overwrite mode). The difference is in what
+ ;; goes in the undo-log and in the intermediate state which might
+ ;; be visible to other post-self-insert-hook. We'll just have to
+ ;; live with it for now.
+ (when skip-whitespace-info
+ (funcall electric-pair-skip-whitespace-function))
+ (delete-region beg (if (eq skip-whitespace-info 'chomp)
+ (point)
+ pos))
+ (forward-char num))
+ ;; Insert matching pair.
+ ;; String pairs
+ ((and (eq syntax 'str) (not overwrite-mode))
+ (if space (insert " "))
+ (save-excursion
+ (insert pair)))
+ ;; Char pairs
+ ((and (memq syntax '(?\( ?\" ?\$))
+ (not overwrite-mode)
+ (or unconditional
+ (not (electric-pair--save-literal-point-excursion
+ (goto-char pos)
+ (funcall electric-pair-inhibit-predicate
+ last-command-event)))))
+ (save-excursion (electric-pair--insert pair num)))))))))
(defun electric-pair-open-newline-between-pairs-psif ()
"Honor `electric-pair-open-newline-between-pairs'.
diff --git a/test/lisp/electric-tests.el b/test/lisp/electric-tests.el
index 9209e1739fd..256fcd0e7dd 100644
--- a/test/lisp/electric-tests.el
+++ b/test/lisp/electric-tests.el
@@ -703,7 +703,30 @@ autowrapping-multi-2
(goto-char (point-max))
(skip-chars-backward "\"")
(mark-sexp -1)))
-
+
+(define-electric-pair-test preserve-balance
+ "\"\n\n" "---\""
+ :expected-string "\"\n\n\""
+ :expected-point 5
+ :modes '(fundamental-mode)
+ :test-in-comments nil
+ :test-in-strings nil
+ :bindings '((electric-pair-preserve-balance . t))
+ :fixture-fn (lambda ()
+ (electric-pair-mode 1)))
+
+(define-electric-pair-test preserve-balance-not-across-fields
+ "\"\n\n" "---\""
+ :expected-string "\"\n\n\"\""
+ :expected-point 5
+ :modes '(fundamental-mode)
+ :test-in-comments nil
+ :test-in-strings nil
+ :bindings '((electric-pair-preserve-balance . t))
+ :fixture-fn (lambda ()
+ (electric-pair-mode 1)
+ (add-text-properties (point-min) (+ (point-min) 2)
+ '(field t))))
;;; Electric quotes
(define-electric-pair-test electric-quote-string
@@ -904,7 +927,6 @@ electric-quote-markdown-in-code
nil :local))
:bindings '((comment-start . "<!--") (comment-use-syntax . t))
:test-in-comments nil :test-in-strings nil)
-
;;; tests for `electric-layout-mode'
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 1 Aug 2026 08:50:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 01 04:50:14 2026 Received: from localhost ([127.0.0.1]:51333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wq5Q5-00019b-Ga for submit <at> debbugs.gnu.org; Sat, 01 Aug 2026 04:50:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wq5Q3-000160-3X for 50236 <at> debbugs.gnu.org; Sat, 01 Aug 2026 04:50:11 -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 1wq5Px-0002SA-Le; Sat, 01 Aug 2026 04:50:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=yepkorKnCsFfmY7BXoqTNIWKYopiKfpA2mA4moUt6fo=; b=mLJtzpP/vxy9EL0l9ybq lrvZ6xRVY/F6v25Zx21MrMtMENnYVqMHUzGpEhYBP56qCFfOggFuUi9rE0VQBCZpckyyyjBnUGEa/ St0EWWd7vJQD7TLNSvmRS+hASZmDcMtPstIpfcvrMSSWO7ujqimwgRRwuG4X4yOEg6zirru3sUphP jIQSi0HM63Fy199WZUsHtZU1ekck5n0BNq+1UV7kYvWp528WO9H1hURK6V/J14AVmCm2Ix65cBWzk H14/R3cYdGoGVLsM/CcTdGF9p6cgF8SRKdWtFBoVNNmwyBdBVVTheLMEnI0v8Pb6+fPpFLmXfX3x5 tJVCd2O9+NJNWQ==; Date: Sat, 01 Aug 2026 11:50:00 +0300 Message-Id: <86cxw2i5s7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Andrew Hyatt <ahyatt@HIDDEN> In-Reply-To: <m25x2aacul.fsf@HIDDEN> (message from Andrew Hyatt on Sun, 19 Jul 2026 17:28:18 -0400) Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> <87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN> <87wlur4cjr.fsf@HIDDEN> <m25x2aacul.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 50236 Cc: yantar92@HIDDEN, 50236 <at> debbugs.gnu.org, arstoffel@HIDDEN, larsi@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Ping! Any further comments or suggestions? > From: Andrew Hyatt <ahyatt@HIDDEN> > Cc: Ihor Radchenko <yantar92@HIDDEN>, Lars Ingebrigtsen > <larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, joaotavora@HIDDEN, > eliz@HIDDEN > Date: Sun, 19 Jul 2026 17:28:18 -0400 > > Augusto Stoffel <arstoffel@HIDDEN> writes: > > Hi Andrew, > > in your proposed patch, why did you choose to change electric-pair-post-self-insert-function directly and > not electric-pair-default-skip-self (or even define a skip-self function specifically for comint)? > > Isn't skip-self for avoiding two closing parens in a row? This doesn't seem related to the problem. > > Also, I should mention over another solution that João had previously implemented for Sly, discussed on the > bug I merged into this one, this issue can be partially solved on `comint` or other mode side by marking the > non-user generated text with a comment syntax, which electric-pair already skips. That solves the issue that > program output in comint can mess up balance, but not that two separate inputs should have independent > balance. > > Maybe that's okay, but then it would force other modes to solve similar issues by using field properties. > > I think that's probably a good idea; using fields to represent different provenance of input is a good general > practice that electric-pair and perhaps other modes may come to rely on. > > I've added Ihor to the discussion since the issue affects Org mode as well (see my email of 22 Aug 2022 > in this thread). WDYT? > > On Sat, 18 Jul 2026, Andrew Hyatt wrote: > > Augusto Stoffel <arstoffel@HIDDEN> writes: > > Is the search bound (and attending local variable) really necessary? Text property search uses an > interval tree so it's better than linear time in the character counts. > > I was able to construct a buffer that, without the bound, took tens of milliseconds to get the previous > field. Basically, lots of different faces, etc, which requires a lot of iteration. I'm not sure what the > normal expectations are, but I thought it best to err on the side of making sure everything stays > optimally fast. > > The 1000 char limit is more than enough for normal comint use, in my experience. > > Okay, if we use this approach then I think the default should ensure at least one screenful is considered, > so maybe 10000.
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 19 Jul 2026 21:28:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 19 17:28:30 2026 Received: from localhost ([127.0.0.1]:56454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wlZ3l-00087Q-G8 for submit <at> debbugs.gnu.org; Sun, 19 Jul 2026 17:28:30 -0400 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]:57599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ahyatt@HIDDEN>) id 1wlZ3j-000871-JG for 50236 <at> debbugs.gnu.org; Sun, 19 Jul 2026 17:28:28 -0400 Received: by mail-qv1-xf34.google.com with SMTP id 6a1803df08f44-8f1e274ccb9so48227906d6.2 for <50236 <at> debbugs.gnu.org>; Sun, 19 Jul 2026 14:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784496502; x=1785101302; 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=PZda2yAjirEIyl+vDFkBiOXA7Egysz+Nooan4b4P0zc=; b=BWOT3LjwAETb7k1XvF6bSFozfiiz2CPfACso57XhaILRehkTCQK2gZZqOUdiB9HLVv Zra0Ju3QN8pHtxAzwsheO7rqgumteZYpV/mB+eZkE394Zj+rBBVOtS811fzrcMiVg734 TGY2i33dT9q3PFinS620CN3x2YQY0R4PBPT5nY7BLjW/77EAZlPtDYY0OVtnHCCTVmUF HeYc68Q6tiZtnOZsRYcuWC+DzNNBjIlBxeXNJbZVoyoKfE/h+ZFqkI0jf2mc4sxrlT26 ECR62Dztnhz2FCegJgxqY8ce2BlVpwimOHEV3EK80Vl73uT8X3Fr6tpbo1D4MHax6IlB /x2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784496502; x=1785101302; 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=PZda2yAjirEIyl+vDFkBiOXA7Egysz+Nooan4b4P0zc=; b=n5guotJYUOHoge6i8RIEvDCqWbz6CwXwxNzD26ElZ73BMJNUxE6UZWVyr0U8BJ05hL 1bV3BqQQwhiIby0tFfi5x92g0FiWKpvJE3FaQ+K8Q1N8Kivn7IXydMw+mv2gL0564Znh 9hHW367Oy9gCrivUgu5yHFePTZBcs3efj+Xgxum7astHvT23JY2KOaeS5T6504M5zuZm Ldr0vGdK9dUsH4ogdWDxWCUWfRtQivWkegBs6VURviPQymTGZd5YlG1FP2e3QVQWJoie ANbEzxjcGlqjxT6X2/EoJbtyD4Ow9uRycaVPB1dOKyrS0cgLg/0ucUf6NRM5aG5ZDux1 i7OA== X-Forwarded-Encrypted: i=1; AHgh+RqffPx4jz6Da+ZrZtkxEtrWWe88/bTQQqmEM/QF0n//5JFhxLFjdiZ5XQYjRCBerUTXD9Lngw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxUgWICj/UZz9bPaEtcD4I74wiHzdly3nDs21cjqx4PLPw7Xr5g iFGQZVpCOBUtAFiCffF2kRMmNhtzRzVMFdZwEjL8daEAlARlCj5tEZG7 X-Gm-Gg: AfdE7clMvbePXin6HAVVEfyELsD7tjpFFHZ/PotWHilMhlObGCB4BiqaNvpUXD7qPk4 eqSehK36OYIAy1lyU1I+mZbt/3rzbcKCq2uWzZGYH9Dfbd2ng8kBVv4CAwyFSdpTLFhcSOHJsJa uuxDLRjlpQ6XuYPkF5WDTOJZadEM7/euSUUBbFb4SoiUYXB5HuqvZr1ARCZy05Ojxg/JA3ohAwt 6xmRqREDL8pC9PB7I8mUVadP3vrB3Twh17TKbMLXYGF1wOuEfpBuRzhrecNnm8Ksf44VBLVPtD8 TEqqVcEnVmFWVbid4vhk8avCbyreFf3GwRWNnkoOuQyJnRf1YWsFcPZ43dXmJOd9RAfk1f8G83k GOHZpJ+dkHRyjKLdmHWUFDRVtKutdVOL+XGFalvDPfT3KtWxBtIFbMZdbf9AwLO5d2wiDRd3agy 326A2Y9aodn9dz7YUheTx5jmvI0hI7bSiT6vhOCHMWOuG4yckeiLRPxo5X+OLzi6zrBwbCcPeN7 nGsX7vibPONtGA7wcOeB8CvhE7qRXMBRNsIKK1g9fAWAxw= X-Received: by 2002:a05:6214:248b:b0:907:598c:e4a5 with SMTP id 6a1803df08f44-90778509df2mr120067116d6.43.1784496501690; Sun, 19 Jul 2026 14:28:21 -0700 (PDT) Received: from MacBookPro ([2600:4041:5d28:b700:803:1864:3bf6:4529]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9077871f766sm75700096d6.46.2026.07.19.14.28.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 14:28:20 -0700 (PDT) From: Andrew Hyatt <ahyatt@HIDDEN> To: Augusto Stoffel <arstoffel@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <87wlur4cjr.fsf@HIDDEN> References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> <87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN> <87wlur4cjr.fsf@HIDDEN> Date: Sun, 19 Jul 2026 17:28:18 -0400 Message-ID: <m25x2aacul.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 50236 Cc: Ihor Radchenko <yantar92@HIDDEN>, 50236 <at> debbugs.gnu.org, eliz@HIDDEN, Lars Ingebrigtsen <larsi@HIDDEN>, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Augusto Stoffel <arstoffel@HIDDEN> writes: > Hi Andrew, > > in your proposed patch, why did you choose to change > electric-pair-post-self-insert-function directly and not > electric-pair-default-skip-self (or even define a skip-self function > specifically for comint)? Isn't skip-self for avoiding two closing parens in a row? This doesn't seem related to the problem. Also, I should mention over another solution that Jo=C3=A3o had previously implemented for Sly, discussed on the bug I merged into this one, this issue can be partially solved on `comint` or other mode side by marking the non-user generated text with a comment syntax, which electric-pair already skips. That solves the issue that program output in comint can mess up balance, but not that two separate inputs should have independent balance. > > Maybe that's okay, but then it would force other modes to solve similar > issues by using field properties. I think that's probably a good idea; using fields to represent different provenance of input is a good general practice that electric-pair and perhaps other modes may come to rely on. > > I've added Ihor to the discussion since the issue affects Org mode as > well (see my email of 22 Aug 2022 in this thread). WDYT? > > On Sat, 18 Jul 2026, Andrew Hyatt wrote: > >> Augusto Stoffel <arstoffel@HIDDEN> writes:=20 >> >> Is the search bound (and attending local variable) really necessary? Te= xt property >> search uses an interval tree so it's better than linear time in the cha= racter counts.=20 >> >> I was able to construct a buffer that, without the bound, took tens of m= illiseconds to get >> the previous field. Basically, lots of different faces, etc, which requi= res a lot of iteration. >> I'm not sure what the normal expectations are, but I thought it best to = err on the side of >> making sure everything stays optimally fast.=20 >> >> The 1000 char limit is more than enough for normal comint use, in my >> experience. > > Okay, if we use this approach then I think the default should ensure at > least one screenful is considered, so maybe 10000. --=-=-= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <p> Augusto Stoffel <arstoffel@HIDDEN> writes: </p> <p> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div>Hi Andrew, </div> <div> <br /></div> <div>in your proposed patch, why did you choose to change electric-pair-post-self-insert-function directly and not electric-pair-default-skip-self (or even define a skip-self function specifically for comint)? </div></blockquote> </p> <p> Isn't skip-self for avoiding two closing parens in a row? This doesn't seem related to the problem. </p> <p> Also, I should mention over another solution that Jo=C3=A3o had previously implemented for Sly, discussed on the bug I merged into this one, this issue can be partially solved on `comint` or other mode side by marking the non-user generated text with a comment syntax, which electric-pair already skips. That solves the issue that program output in comint can mess up balance, but not that two separate inputs should have independent balance. </p> <p> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div> Maybe that's okay, but then it would force other modes to solve similar issues by using field properties. </div></blockquote> </p> <p> I think that's probably a good idea; using fields to represent different provenance of input is a good general practice that electric-pair and perhaps other modes may come to rely on. </p> <p> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div> I've added Ihor to the discussion since the issue affects Org mode as well (see my email of 22 Aug 2022 in this thread). WDYT? </div> <div> <br /></div> <div>On Sat, 18 Jul 2026, Andrew Hyatt wrote: </div> <div> <br /></div> <div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> <div>Augusto Stoffel <arstoffel@HIDDEN> writes:=20 </div> <div> <br /></div> <div>Is the search bound (and attending local variable) really necessary? T= ext property search uses an interval tree so it's better than linear time in the charact= er counts.=20 </div> <div> <br /></div> <div>I was able to construct a buffer that, without the bound, took tens of= milliseconds to get the previous field. Basically, lots of different faces, etc, which requires= a lot of iteration. I'm not sure what the normal expectations are, but I thought it best to err= on the side of making sure everything stays optimally fast.=20 </div> <div> <br /></div> <div>The 1000 char limit is more than enough for normal comint use, in my experience. </div></blockquote> </div> <div> <br /></div> <div>Okay, if we use this approach then I think the default should ensure at least one screenful is considered, so maybe 10000. </div></blockquote> </p> --=-=-=--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 19 Jul 2026 08:19:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 19 04:19:15 2026 Received: from localhost ([127.0.0.1]:52106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wlMjz-0001zu-71 for submit <at> debbugs.gnu.org; Sun, 19 Jul 2026 04:19:15 -0400 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:55736) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <arstoffel@HIDDEN>) id 1wlMjw-0001zd-Jl for 50236 <at> debbugs.gnu.org; Sun, 19 Jul 2026 04:19:13 -0400 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-c15d3cd51b2so1061834166b.3 for <50236 <at> debbugs.gnu.org>; Sun, 19 Jul 2026 01:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784449146; x=1785053946; darn=debbugs.gnu.org; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Kk1PFgoLPbsTGdLvx98Jw/bCHYtdgHrEOFHXKbnGQoA=; b=gBmLCf1HXNHVZo/ysnlhA8MV6IxyGcLG0m6VezkelaRBBh2p08XTOsh53g3apXpIKb uLo6u1O9TPPohXbzrXGBPm6GIW3+Su3phio1C8+EPEAKGGj1GJd/Kxoy6LWHZCqEY87x iEqps9T9JvKKlGiwXQEwO6zQBUZTNKEhJWznetX53TW6tab9K2/tY0KTrsZN+5+Q5q11 gPBWWvXShkhMAz5Gv+B/+5+WAXtxnAf2aZPxHURvb3EQlSUcWWSi1tj8vfWZRO6/TFye 7lXJm6NKLqmxMRr77/Xp6gXhu6D1MS/MM1EWk4Ppby1fvoaP9d1g81iH16wY9ML6Gpbo EA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784449146; x=1785053946; h=content-type:mime-version: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=Kk1PFgoLPbsTGdLvx98Jw/bCHYtdgHrEOFHXKbnGQoA=; b=d5x4vlG0ANf8+uzX4f8Q7j9yXa//KIPEUxKbxDojVh1k2xXfll2FGPjqpmgtRzGtgs IGLLyJxflOHab2IqHYK0telgy3KtYC6/t+iIDponN+AnePzulhIq+XZiTKE7VXne7OOr w+MUsASchDNrnLN7k9dKdQiING8Sv0tRQDbhZq6B6ZB7dAmEscAauF/2uzI6jY/M3imy CJQUezIoLb4wpQpk1zjUQHwY5T8Kf5dWlOqYImrKdkSKWn4eb1QAZcQBWpdqU7PrmJdf xldzpJG6OauHj6bC+vw3Z+UuwtV88CB1vULmcX5pA/HPqn9BnhWLtxdD0/eyExaUSbOX oZNg== X-Forwarded-Encrypted: i=1; AHgh+RoRw06QEs0IzN8JCmbxcZEngpd/PcNOZfdA1vVoFBDVUoIXA/kq0oOnexsqbXTiFUX3EL3pQQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyHhBtaTQhaiZqriHR3XydsDPKGHSx2ZRXHxqLuc3JDkiabgvH6 8MKFku/NL7F93AP7v5I85N5w9XIH22h+CkrcRgSgHZlJzg5XSbH6XViv X-Gm-Gg: AfdE7cnR2JHbp1TvolYFidcF2tNky0NDhp0wD15DkheLzgUFNn+tqR3G4V9krc7kkvW 0Ppcq5297WLYVvC6mp9/qRvp+sL2ZNLNWVl0LfCEUGRIjYRA860UvsKHhwkXKi9m1rBlfwnxzjk uupdNZR950l0+ry7d5uu50kPIq4ZZIsUFFKWRCAeJ+tTTswbLBQkBYHCJyn0A+x+W2FMfICxIWU Ut+QeReB5pe0WnuEDYCr655zXGTQiEJmynkdQbza2do7VU7tMKY17DlotOj/vhL2DkUBqP3EeWV mqY902HOEQ/pTThZM73QWwHErvM/OA7JWdbsT5EoqAPkaEy4RusldDsYwjeDjT9KuAouCn5+sFX BligGp/DEVdou+/qBKk3DVWUG3/bDFGVL0gnwrek2Era3GskZb4+5 X-Received: by 2002:a17:907:e1d3:20b0:c15:b67b:523e with SMTP id a640c23a62f3a-c16b46f14c6mr251217566b.19.1784449146288; Sun, 19 Jul 2026 01:19:06 -0700 (PDT) Received: from ars3 ([2a02:8109:8a95:9a00::2f5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1740bf660fsm310176966b.58.2026.07.19.01.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 01:19:05 -0700 (PDT) From: Augusto Stoffel <arstoffel@HIDDEN> To: Andrew Hyatt <ahyatt@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <m2a4roat46.fsf@HIDDEN> References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> <87zezo4uah.fsf@HIDDEN> <m2a4roat46.fsf@HIDDEN> Date: Sun, 19 Jul 2026 10:19:04 +0200 Message-ID: <87wlur4cjr.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 50236 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, eliz@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Hi Andrew, in your proposed patch, why did you choose to change electric-pair-post-self-insert-function directly and not electric-pair-default-skip-self (or even define a skip-self function specifically for comint)? Maybe that's okay, but then it would force other modes to solve similar issues by using field properties. I've added Ihor to the discussion since the issue affects Org mode as well (see my email of 22 Aug 2022 in this thread). WDYT? On Sat, 18 Jul 2026, Andrew Hyatt wrote: > Augusto Stoffel <arstoffel@HIDDEN> writes: > > Is the search bound (and attending local variable) really necessary? Text property > search uses an interval tree so it's better than linear time in the character counts. > > I was able to construct a buffer that, without the bound, took tens of milliseconds to get > the previous field. Basically, lots of different faces, etc, which requires a lot of iteration. > I'm not sure what the normal expectations are, but I thought it best to err on the side of > making sure everything stays optimally fast. > > The 1000 char limit is more than enough for normal comint use, in my > experience. Okay, if we use this approach then I think the default should ensure at least one screenful is considered, so maybe 10000.
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 18 Jul 2026 21:24:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 18 17:24:53 2026 Received: from localhost ([127.0.0.1]:50068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wlCWi-0000hM-Nu for submit <at> debbugs.gnu.org; Sat, 18 Jul 2026 17:24:53 -0400 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]:42300) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ahyatt@HIDDEN>) id 1wlCWg-0000h1-Cm for 50236 <at> debbugs.gnu.org; Sat, 18 Jul 2026 17:24:51 -0400 Received: by mail-qv1-xf34.google.com with SMTP id 6a1803df08f44-90327237340so26723876d6.1 for <50236 <at> debbugs.gnu.org>; Sat, 18 Jul 2026 14:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784409885; x=1785014685; 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=ERtacKmaTlf2FD3jW7bU0XVb8fjobS9KkyMsKjw4Nbo=; b=S1QtSh91bmBWbG7yAP7TseLjtpksRWo4QX2eX2FRyqZ4/ysyElZMMKmvwHs5NWP1Wb yggoks+JA1A6i6aZWu6xhRPqyM13C48qv68knPavhR0k47cOTUW1dEEGOMW13bEl5lN4 qgeIL/e17zQkx3MrMRA83YLJQ53NDE4DvjymMK5/dX383HwGFvzU+FsMTOsGT+I3XKSB m7VYKgsmDGvt2NyFWku3lEIBK9/W+Js4g4SOviWFoGZs4aG980MTr0+gMPYQY77K83Md giCJdsqGamF70CQ3S6yAhdk/Kdj7j62afnUbo4XEiOdtWxyNCyMpnC9s7mSfoitpGEFl evNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784409885; x=1785014685; 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=ERtacKmaTlf2FD3jW7bU0XVb8fjobS9KkyMsKjw4Nbo=; b=hb/xZhO6Qs9Cn+Qvb9d9MZ0fijA9khwbpa57nATPvF95IhVBau684kBqDBT0dzn7cG sQqi6tbFmPqzbt3RJeHTHiydO/+CKR9dMVJlW05N9ZZhf8o3pjQP7MSeQbbMbnLY3ACB 0fibO3125otHM69GrXYrOkhHq5pKrr1vO7MIf7O74wsXFU/FysEvtgU0P901zfesNJ2r DF4QgGO0dhYrUozVM4RjweylXBZecwyquILhbmDRM5dnBjWJY/S8DTsKK/aTQiXyxqt3 WcbAFLYoWUeP2aSehq7oY0Zvz5c0Sflsyq7V+6k0TaF7xrZ1J2Oj6lm5eM1X9r6+6u7k VpLA== X-Forwarded-Encrypted: i=1; AHgh+RpTblH3YRH1FUX4scAAxRRXX0ZRDkRNyq1KuXZrlluiZYPJ0Zi7z1k6CdC8a8YFMm0PY4paMg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzGBZyo4WMTptm3Dz5IPp0sLw46W8bNfUXvPvPMvWtc1R6bc+gM RCGsRTgYK2IPATZbNEOEnBElbJPgPDYOS/6yC2R3I93QbY7QBFxt+HWt X-Gm-Gg: AfdE7ck4p/jeJjDOyGKj4YxnGsOeBqja8h9GATM7sLqmi4R/Yd+AUJgjWh9lWoD9ahz K0rgBjxYVCwkwkFmml6sDBczcYs2F6mfZ3Nbhu07g9cDyzK1Sdxrq04y4zmlagEfEjXpiocspcH Bf9N7+GO1xp5U1+SYNYOWoxJwnk2Qah4OfUVXAPhHJPTZy07Heaid9jgdXzQlJuUZKwE2hAeV5i moz8uSNUVU4sXH/w3FgxglPz/PnlGH29zTW/YF14ucccMcb9v6/nHe6QOpfqLKZYRSf2N2KaWLy iUJbLC6oT/fdjroxyu+0enrLLza3ccNuXrqkYJsLe8CktA2ANpCxKDf2LldT5rG/Uz15Wr7HKH7 EYM51Cu8IeKpSDoIkTQmTHpyCJCkLuFaQLq0c137LBKDx1lxEBM48R4/1oIlej+D2IKZUhk/E33 hmL9VquDq9gehSdustDu2RmdsR05NdV+Qx84pPFceviC2/Xdoraeyjo6Y2bP38NlR4ranMHoqZw xcvj6YopRWwgCIhqC6riRrKUrQ4hwAjcoYG+P7LL0qLT3M= X-Received: by 2002:a05:6214:53c6:b0:907:5389:c62c with SMTP id 6a1803df08f44-90768eb5397mr135969586d6.26.1784409884557; Sat, 18 Jul 2026 14:24:44 -0700 (PDT) Received: from ahyatt-home.local ([2600:4041:5d28:b700:38cf:d43c:3ce6:2569]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9077871dec5sm50326966d6.44.2026.07.18.14.24.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2026 14:24:43 -0700 (PDT) From: Andrew Hyatt <ahyatt@HIDDEN> To: Augusto Stoffel <arstoffel@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <87zezo4uah.fsf@HIDDEN> References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> <87zezo4uah.fsf@HIDDEN> Date: Sat, 18 Jul 2026 17:24:41 -0400 Message-ID: <m2a4roat46.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 50236 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, eliz@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain Augusto Stoffel <arstoffel@HIDDEN> writes: > On Thu, 16 Jul 2026, Andrew Hyatt wrote: > >> I also noticed this issue, and submitted a separate bug which was essentially a dupe of >> this. After reading through this thread and previous discussion, I tried a fix that hopefully >> is both performant and, in practice, will almost completely solve this problem. >> >> The idea is that we do narrow to the field (when the region is not active), but we limit the >> search backward and forward for the field boundary to 1000 chars (a new buffer local >> variable). This keeps performance good, and if we can't find a limit, we fall back to the >> previous broken behavior. It's better than leaving this not fixed, IMHO. It's worth noting >> that the search for field boundaries is in C, so it is pretty fast. > > Is the search bound (and attending local variable) really necessary? > Text property search uses an interval tree so it's better than linear > time in the character counts. I was able to construct a buffer that, without the bound, took tens of milliseconds to get the previous field. Basically, lots of different faces, etc, which requires a lot of iteration. I'm not sure what the normal expectations are, but I thought it best to err on the side of making sure everything stays optimally fast. The 1000 char limit is more than enough for normal comint use, in my experience. > >> >> The proposed fix above, to check after the pair has been found is also reasonable, but I >> think the code would be a bit less clear; and in theory it'd have the same issue where >> we'd need to bound the search for the boundary between the pairs. >> >> The implementation patch is attached, if this seems reasonable, I need to flesh this out >> by adding tests and seeing if the docs need to be changed. >> >> [4. first draft of proposed patch to electric-pair-mode --- text/x-patch; 0001-First-attempt-to-fix-eletric-pairs-by-restricting-to.patch]... --=-=-= Content-Type: text/html <p> Augusto Stoffel <arstoffel@HIDDEN> writes: </p> <p> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On Thu, 16 Jul 2026, Andrew Hyatt wrote: </div> <div> <br /></div> <div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>I also noticed this issue, and submitted a separate bug which was essentially a dupe of this. After reading through this thread and previous discussion, I tried a fix that hopefully is both performant and, in practice, will almost completely solve this problem. </div> <div> <br /></div> <div>The idea is that we do narrow to the field (when the region is not active), but we limit the search backward and forward for the field boundary to 1000 chars (a new buffer local variable). This keeps performance good, and if we can't find a limit, we fall back to the previous broken behavior. It's better than leaving this not fixed, IMHO. It's worth noting that the search for field boundaries is in C, so it is pretty fast. </div></blockquote> </div> <div> <br /></div> <div>Is the search bound (and attending local variable) really necessary? Text property search uses an interval tree so it's better than linear time in the character counts. </div></blockquote> </p> <p> I was able to construct a buffer that, without the bound, took tens of milliseconds to get the previous field. Basically, lots of different faces, etc, which requires a lot of iteration. I'm not sure what the normal expectations are, but I thought it best to err on the side of making sure everything stays optimally fast. </p> <p> The 1000 char limit is more than enough for normal comint use, in my experience. </p> <p> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> The proposed fix above, to check after the pair has been found is also reasonable, but I think the code would be a bit less clear; and in theory it'd have the same issue where we'd need to bound the search for the boundary between the pairs. </div> <div> <br /></div> <div>The implementation patch is attached, if this seems reasonable, I need to flesh this out by adding tests and seeing if the docs need to be changed. </div> <div> <br /></div> <div>[4. first draft of proposed patch to electric-pair-mode — text/x-patch; 0001-First-attempt-to-fix-eletric-pairs-by-restricting-to.patch]… </div></blockquote> </div></blockquote> </p> --=-=-=--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 18 Jul 2026 07:43:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 18 03:43:44 2026 Received: from localhost ([127.0.0.1]:44107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wkzi4-0004M7-D6 for submit <at> debbugs.gnu.org; Sat, 18 Jul 2026 03:43:44 -0400 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:52724) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <arstoffel@HIDDEN>) id 1wkzi2-0004Lo-D7 for 50236 <at> debbugs.gnu.org; Sat, 18 Jul 2026 03:43:43 -0400 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-c1677c91969so458274766b.1 for <50236 <at> debbugs.gnu.org>; Sat, 18 Jul 2026 00:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784360616; x=1784965416; darn=debbugs.gnu.org; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BbKFdEYEDjqB7KjYV9SpIUCLf4Cm7AAu0I6/j2uDDP0=; b=rUZUvD3ZhijKvVeucWbZnlZZ3FQQA1YE+g+D7/+lxcPm4B/TxFauv3zJgfU34JYM3Z nzAitYyvS01LtIblFgta9f1wgzx0QKcKdVKbPikSp2DjwqsI34if0nRZ3ia5ZsiZuEa3 isZm1wCnhTuU9G42SIqY7x6A8VUMFfhfHEqFwXUyQs1W4tgnTvOV/HHZRwhLiPnEAepX w9/7PPbMjEnR/TslE6QWFIlKThM5dutzHOO3Yoe6ILEqYJ4vajEsx2no3g29us1yvZFQ 9T57wlPPO3+yZEInbCBvDM9+0/wcCkFVR+2nR60MdFVyIF+uI0J8rAyQq7JmOgTgY+VZ SwAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784360616; x=1784965416; h=content-type:mime-version: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=BbKFdEYEDjqB7KjYV9SpIUCLf4Cm7AAu0I6/j2uDDP0=; b=VvTH1xu/An4vzo5Y1VKzaEi/WQifcLvRH5JGVelzhqiN4366NcSEH0WKQCWLFBAXlj IbvN4KUvK7DdepMuTQhgxDn9clBNZ1O97o277HcnmuMHHdHe8G+J5WOOCRroHC1uINwV FfV2xqWPO4cdSYgehGHSs6t+CdmTnwevbo5Z84HYRgEZCiZYXXHKlBZX8bwif868Oj91 7GiYxclop/9ycZTmRHXjZmQs9+uB3dWGhfwVLhC9B58m1t14YppjsYoDVlpaiaxlRzu9 dtCIz7aSd6RZworwKVqoh16ZFMGxnJwtWYpAIhev7E0eAVSutzjYDGsR3koic2ZExzNx jljQ== X-Forwarded-Encrypted: i=1; AHgh+Rqz1BxTw/WgmvT2WWnB/okCkszrfNg5Q4r2Lal02Vp8mh2a4t00jWAoR6Gty/9204Dtg+kRGw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxlVfi6fXxMIT0yHCb1OjtbSnFeoCRavKAZg3cGTfvTQsdqIHle a4bZ2Inz5nCh8LFtylNQH8i+HNlW6tWSRYSRWa6Ss0/tR6exbUhplLww X-Gm-Gg: AfdE7cmTz0oD376FYjWE3sfRexSGFIgIqtuQT0LzpW8X6IXIiZcfsK+FLjpM5vNGKye REgpbtuqisLvIPFq17SEPhrhwbV9zPge6mUQRfGfdg0vwZCf3rTn34akAOYAZpTZNPlFXTSnFw+ 0MNFc2ljtr9Nn9Q55ZlcgvcrezYHwe2w/QFjtC5V/4lahptzAJPvxa0xJJOxjPFEZumozVvl69h QypgvxWjKaQ/VIVpnDqmxU7axIGYiO1r17tr4JJGS3I6RVeDNS00uGXXCWLuyBv4s9TW+zNH/o4 ys41j8r8K3+qlb8JggduQVWYKl9JwX12LIhcE3YAQPSGEHgwm3WI5lmb1wiCgOyxvDJIoh5FwVb Cfqn0efTi7lpcHX6U11XIQ9fOPW3l5Mh+lq5A/IqthGqh7kI1s7mA X-Received: by 2002:a17:907:9803:b0:c12:3e8e:2ac1 with SMTP id a640c23a62f3a-c16b48074dcmr273826866b.51.1784360615869; Sat, 18 Jul 2026 00:43:35 -0700 (PDT) Received: from ars3 ([2a02:8109:8a95:9a00::2f5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c17009ae10fsm183221666b.10.2026.07.18.00.43.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2026 00:43:35 -0700 (PDT) From: Augusto Stoffel <arstoffel@HIDDEN> To: Andrew Hyatt <ahyatt@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <m2qzl2bfi3.fsf@HIDDEN> References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> <87k06yoseg.fsf@HIDDEN> <m2qzl2bfi3.fsf@HIDDEN> Date: Sat, 18 Jul 2026 09:43:34 +0200 Message-ID: <87zezo4uah.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 50236 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 50236 <at> debbugs.gnu.org, eliz@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) On Thu, 16 Jul 2026, Andrew Hyatt wrote: > I also noticed this issue, and submitted a separate bug which was essentially a dupe of > this. After reading through this thread and previous discussion, I tried a fix that hopefully > is both performant and, in practice, will almost completely solve this problem. > > The idea is that we do narrow to the field (when the region is not active), but we limit the > search backward and forward for the field boundary to 1000 chars (a new buffer local > variable). This keeps performance good, and if we can't find a limit, we fall back to the > previous broken behavior. It's better than leaving this not fixed, IMHO. It's worth noting > that the search for field boundaries is in C, so it is pretty fast. Is the search bound (and attending local variable) really necessary? Text property search uses an interval tree so it's better than linear time in the character counts. > > The proposed fix above, to check after the pair has been found is also reasonable, but I > think the code would be a bit less clear; and in theory it'd have the same issue where > we'd need to bound the search for the boundary between the pairs. > > The implementation patch is attached, if this seems reasonable, I need to flesh this out > by adding tests and seeing if the docs need to be changed. > > [4. first draft of proposed patch to electric-pair-mode --- text/x-patch; 0001-First-attempt-to-fix-eletric-pairs-by-restricting-to.patch]...
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
Received: (at 50236) by debbugs.gnu.org; 17 Jul 2026 00:56:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 16 20:56:48 2026
Received: from localhost ([127.0.0.1]:34011 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wkWsh-0007oH-HB
for submit <at> debbugs.gnu.org; Thu, 16 Jul 2026 20:56:48 -0400
Received: from mail-qk1-x735.google.com ([2607:f8b0:4864:20::735]:50504)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <ahyatt@HIDDEN>) id 1wkWse-0007nl-K7
for 50236 <at> debbugs.gnu.org; Thu, 16 Jul 2026 20:56:46 -0400
Received: by mail-qk1-x735.google.com with SMTP id
af79cd13be357-9309d4ea213so185587585a.1
for <50236 <at> debbugs.gnu.org>; Thu, 16 Jul 2026 17:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1784249799; x=1784854599; 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=7WKRS02Hp8KGeYFtuhm3juEpCxjPZoQ5LaF7Wz9J/c8=;
b=I/vW2oU0DhCt3ZfC4SKmEFdKP0/7kzH+rjTE/38Xr4Ju1WGr/g1GcArPAKN+z6Qivo
vF5yCaYr4Y3ZZOwexGapQ3EXmcT+s5grsuPEok7BzRm7t6tx3FtAUI0UeYX7Qrqspwv0
33BojLGyaxwD4avDuEwZbxW9K2uR0+gkC4Rec5un2fVl6rDJ5OzCEb3pwDWVlSPSsBfF
JDT3sDjq3IeogmUgHSUDhnmrIxsvJ2Jm7QgfkvvgSh4INZsIgSEr6+ZOe3Pi26skRc8z
XWb7RiDkv3gt1h5cQ8A5ThOXE+legCV9PcI+ygC58IW2U83jwPaD0VLs4qgcnEubaSfZ
2OXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1784249799; x=1784854599;
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=7WKRS02Hp8KGeYFtuhm3juEpCxjPZoQ5LaF7Wz9J/c8=;
b=RUG+Ou3eLjB7hsXiSc9RUAwbuSwCHfgRkAX9q4EdpcZQiL4N51wImDztEKtUEnHaYu
BYcfBwbl62XJBVfRffAmyNeq3cEsSUJzRQxCaijxVB5ecJrNHSZQe1VxRribU584vfjc
ESxBEvUTKDOZ6zcAHZs4cJzYuh33ittI0hr1RxmmnY5K3DTOTo4zbT+g2SABSKi6pLNQ
J8p8gQpfRvMDZjzdPuhkaGHbuk3yPvx+Pmw7OqqrCqbuvYSc2ZDG1PjNNYqMLug+ZHHI
CVw5jw1waQS1gTxUxQ6dgXjrzPYV+eZmTvRPHp44yfbXAJ1Wk23H6Muaxfx17e0VQUSt
Bxvg==
X-Forwarded-Encrypted: i=1;
AHgh+RpQb8IYoaRB+neJ55Dlg11TTtcaSxa6K2KaN8gfCGXxsQP196GPlOAn/dWUFtbjIw6LsXaA/A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Ywx7GEbeEguGaker5MmHhZ7gq9hFk16gATM/vjMawqP+WusgskJ
RpsdyMD9kWRnfogEEsZwgkmsWjr586UQ014IE5kLk0Y6ZuN4yMyL2sLD
X-Gm-Gg: AfdE7cksmz4NdFmQjS09te21280Phv6gvngrDajnbU7nLiO/fJsH2pDtjZIpgO38Mgk
uHBVdJpsAbUFtwbTeYku+UGOVXOdNyXi491KJt9H8JhZWDHPvVVVEErLtmIYHzNF9cin45rJOed
Y0q5MIfNjX5EGaOxxJdk3rJ+yD/5TApr96QPA/EcK2tzrBhFY8IoSVwShPNXxcdIhJQCRKa4oBy
KMDDPn5Uzec9dNQhcSbCV21/Is6w+O8eMRdO5RwG5IWQl5pwRg+sg6yzSEKFwqd1yTNE+uX8KnQ
33zzhVpxtiK37MKtdm+QPHTQIWk1dWC3wkm9oHrUTYAhr/lv8Royp92M7P+7I9cre4yG0J5WhHN
MZ4U/f5DMtx2RvaXej7Dp73Du1cRQ8h7mPHSFBTVEJX2bI6XXHr1YRx7huzYXSokV8e5GxuuE3V
b8aDMXJlglyVBCiZjOKxlkFJZmIGbIwPjc+nAx0IlUvxagjK2gESsl4LJr9jsCECSNBR97/rbQD
JayF93pj8xF0hMbiTrCHA+UK04dhplgwK4YrPWr9codSmg=
X-Received: by 2002:a05:620a:2a0b:b0:92e:5554:a80e with SMTP id
af79cd13be357-930b3f1df82mr63578985a.39.1784249798666;
Thu, 16 Jul 2026 17:56:38 -0700 (PDT)
Received: from ahyatt-home.local ([2600:4041:5d28:b700:c8c2:6526:f230:7c13])
by smtp.gmail.com with ESMTPSA id
af79cd13be357-930b542acdfsm15368285a.22.2026.07.16.17.56.37
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 16 Jul 2026 17:56:37 -0700 (PDT)
From: Andrew Hyatt <ahyatt@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint
In-Reply-To: <87k06yoseg.fsf@HIDDEN>
References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN>
<87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN>
<875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN>
<87k06yoseg.fsf@HIDDEN>
Date: Thu, 16 Jul 2026 20:56:36 -0400
Message-ID: <m2qzl2bfi3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 50236
Cc: eliz@HIDDEN, 50236 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>,
joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--=-=-=
Content-Type: multipart/alternative; boundary="==-=-="
--==-=-=
Content-Type: text/plain
+joaotavora, eliz
Lars Ingebrigtsen <larsi@HIDDEN> writes:
> Augusto Stoffel <arstoffel@HIDDEN> writes:
>
>> This makes sense. However, in comint the "input" field has no field
>> property; only the output is labeled as such. So the suggestion to do
>> something special if inside a field wouldn't solve the original problem
>> described in the bug.
>
> Ah, right.
>
>> So the conclusion seems to be that a comint-specific
>> electric-pair-skip-self function is needed (namely, one that narrows to
>> the current field provided the current field property is nil, to avoid
>> those performance issues.)
>
> The other possible solution (that I mentioned, but didn't expand on) is
> that we could just fix this in electric-pair without relying on
> narrow-to-field. That is, once electric-pair has found the matching
> pair, we just look at the region between the two chars and see whether
> they are part of the same field. That should be reasonably fast, since
> electric-pair already limits the range it's willing to search for a
> pair.
I also noticed this issue, and submitted a separate bug which was
essentially a dupe of this. After reading through this thread and
previous discussion, I tried a fix that hopefully is both performant
and, in practice, will almost completely solve this problem.
The idea is that we do narrow to the field (when the region is not
active), but we limit the search backward and forward for the field
boundary to 1000 chars (a new buffer local variable). This keeps
performance good, and if we can't find a limit, we fall back to the
previous broken behavior. It's better than leaving this not fixed,
IMHO. It's worth noting that the search for field boundaries is in C,
so it is pretty fast.
The proposed fix above, to check after the pair has been found is also
reasonable, but I think the code would be a bit less clear; and in
theory it'd have the same issue where we'd need to bound the search for
the boundary between the pairs.
The implementation patch is attached, if this seems reasonable, I need
to flesh this out by adding tests and seeing if the docs need to be
changed.
--==-=-=
Content-Type: text/html
<p>
+joaotavora, eliz
</p>
<p>
Lars Ingebrigtsen <larsi@HIDDEN> writes:
</p>
<p>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Augusto Stoffel <arstoffel@HIDDEN> writes:
</div>
<div>
<br /></div>
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>This makes sense. However, in comint the "input" field has no field
property; only the output is labeled as such. So the suggestion to do
something special if inside a field wouldn't solve the original problem
described in the bug.
</div></blockquote>
</div>
<div>
<br /></div>
<div>Ah, right.
</div>
<div>
<br /></div>
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>So the conclusion seems to be that a comint-specific
electric-pair-skip-self function is needed (namely, one that narrows to
the current field provided the current field property is nil, to avoid
those performance issues.)
</div></blockquote>
</div>
<div>
<br /></div>
<div>The other possible solution (that I mentioned, but didn't expand on) is
that we could just fix this in electric-pair without relying on
narrow-to-field. That is, once electric-pair has found the matching
pair, we just look at the region between the two chars and see whether
they are part of the same field. That should be reasonably fast, since
electric-pair already limits the range it's willing to search for a
pair.
</div></blockquote>
</p>
<p>
I also noticed this issue, and submitted a separate bug which was
essentially a dupe of this. After reading through this thread and
previous discussion, I tried a fix that hopefully is both performant
and, in practice, will almost completely solve this problem.
</p>
<p>
The idea is that we do narrow to the field (when the region is not
active), but we limit the search backward and forward for the field
boundary to 1000 chars (a new buffer local variable). This keeps
performance good, and if we can't find a limit, we fall back to the
previous broken behavior. It's better than leaving this not fixed,
IMHO. It's worth noting that the search for field boundaries is in C,
so it is pretty fast.
</p>
<p>
The proposed fix above, to check after the pair has been found is also
reasonable, but I think the code would be a bit less clear; and in
theory it'd have the same issue where we'd need to bound the search for
the boundary between the pairs.
</p>
<p>
The implementation patch is attached, if this seems reasonable, I need
to flesh this out by adding tests and seeing if the docs need to be
changed.
</p>
--==-=-=--
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-First-attempt-to-fix-eletric-pairs-by-restricting-to.patch
Content-Description: first draft of proposed patch to electric-pair-mode
From 29bc0211e90b86caeb4051a02259bf7b995c7885 Mon Sep 17 00:00:00 2001
From: Andrew Hyatt <ahyatt@HIDDEN>
Date: Thu, 16 Jul 2026 20:33:08 -0400
Subject: [PATCH] First attempt to fix eletric pairs by restricting to fields
---
lisp/elec-pair.el | 186 ++++++++++++++++++++++++++--------------------
1 file changed, 104 insertions(+), 82 deletions(-)
diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
index 54fbc960b0f..5f338f686f5 100644
--- a/lisp/elec-pair.el
+++ b/lisp/elec-pair.el
@@ -228,6 +228,16 @@ electric-pair-skip-whitespace-chars
(const :tag "Newline" ?\n))
(repeat (character :value " "))))
+(defvar-local electric-pair-max-field-size 1000
+ "Maximum number of characters to search for a field boundary.
+
+This is used to limit how far we search the buffer to find a field
+boundary to restrict the search for matching pairs to. If there is no
+field boundary within this many characters, then we will not attempt to
+restrict the matching, otherwise we only match within the field.
+
+This is buffer local because different modes may want to tweak this.")
+
(defvar-local electric-pair-skip-whitespace-function
#'electric-pair--skip-whitespace
"Function to use to move point forward over whitespace.
@@ -620,88 +630,100 @@ electric-pair-post-self-insert-function
(both as defined by the major mode's syntax table). This is
done by looking up the variables
`electric-pair-inhibit-predicate', `electric-pair-skip-self'
- and `electric-pair-skip-whitespace' (which see)."
- (let* ((pos (and electric-pair-mode (electric--after-char-pos)))
- (num (when pos (prefix-numeric-value current-prefix-arg)))
- (beg (when num (- pos num)))
- (skip-whitespace-info))
- (pcase (electric-pair-syntax-info last-command-event)
- (`(,syntax ,pair ,unconditional ,space)
- (cond
- ((null pos) nil)
- ((zerop num) nil)
- ;; Wrap a pair around the active region.
- ;;
- ((and (memq syntax '(?\( ?\) ?\" ?\$)) (use-region-p))
- ;; FIXME: To do this right, we'd need a post-self-insert-function
- ;; so we could add-function around it and insert the closer after
- ;; all the rest of the hook has run.
- (if (or (eq syntax ?\")
- (and (eq syntax ?\))
- (>= (point) (mark)))
- (and (not (eq syntax ?\)))
- (>= (mark) (point))))
- (save-excursion
- (goto-char (mark))
- (electric-pair--insert pair num))
- (delete-region beg pos)
- (electric-pair--insert pair num)
- (goto-char (mark))
- (electric-pair--insert last-command-event num)))
- ;; Backslash-escaped: no pairing, no skipping.
- ((save-excursion
- (goto-char beg)
- (not (evenp (skip-syntax-backward "\\"))))
- (let ((current-prefix-arg (1- num)))
- (electric-pair-post-self-insert-function)))
- ;; Skip self.
- ((and (memq syntax '(?\) ?\" ?\$))
- (and (or unconditional
- (if (functionp electric-pair-skip-self)
- (electric-pair--save-literal-point-excursion
- (goto-char pos)
- (funcall electric-pair-skip-self
- last-command-event))
- electric-pair-skip-self))
- (save-excursion
- (when (and
- (not (and unconditional (eq syntax ?\")))
- (setq skip-whitespace-info
- (if (and
- (not
- (eq electric-pair-skip-whitespace
- 'chomp))
- (functionp electric-pair-skip-whitespace))
- (funcall electric-pair-skip-whitespace)
- electric-pair-skip-whitespace)))
- (funcall electric-pair-skip-whitespace-function))
- (eq (char-after) last-command-event))))
- ;; This is too late: rather than insert&delete we'd want to only
- ;; skip (or insert in overwrite mode). The difference is in what
- ;; goes in the undo-log and in the intermediate state which might
- ;; be visible to other post-self-insert-hook. We'll just have to
- ;; live with it for now.
- (when skip-whitespace-info
- (funcall electric-pair-skip-whitespace-function))
- (delete-region beg (if (eq skip-whitespace-info 'chomp)
- (point)
- pos))
- (forward-char num))
- ;; Insert matching pair.
- ;; String pairs
- ((and (eq syntax 'str) (not overwrite-mode))
- (if space (insert " "))
- (save-excursion
- (insert pair)))
- ;; Char pairs
- ((and (memq syntax '(?\( ?\" ?\$))
- (not overwrite-mode)
- (or unconditional
- (not (electric-pair--save-literal-point-excursion
- (goto-char pos)
- (funcall electric-pair-inhibit-predicate
- last-command-event)))))
- (save-excursion (electric-pair--insert pair num))))))))
+ and `electric-pair-skip-whitespace' (which see).
+
+If possible, this function will attempt to match delimiters for the
+current field only. However, we limit how much we scan for the
+beginning and end of the field to limit possible computation, so in
+large fields this falls back to using the entire buffer for matching."
+ (with-restriction
+ (let* ((subtracted-point (- (point) electric-pair-max-field-size))
+ (beginning (field-beginning nil nil (max (point-min) subtracted-point))))
+ (if (or (use-region-p) (= beginning subtracted-point)) (point-min) beginning))
+ (let* ((added-point (+ (point) electric-pair-max-field-size))
+ (end (field-end nil nil (min (point-max) added-point))))
+ (if (or (use-region-p) (= end added-point)) (point-max) end))
+ (let* ((pos (and electric-pair-mode (electric--after-char-pos)))
+ (num (when pos (prefix-numeric-value current-prefix-arg)))
+ (beg (when num (- pos num)))
+ (skip-whitespace-info))
+ (pcase (electric-pair-syntax-info last-command-event)
+ (`(,syntax ,pair ,unconditional ,space)
+ (cond
+ ((null pos) nil)
+ ((zerop num) nil)
+ ;; Wrap a pair around the active region.
+ ;;
+ ((and (memq syntax '(?\( ?\) ?\" ?\$)) (use-region-p))
+ ;; FIXME: To do this right, we'd need a post-self-insert-function
+ ;; so we could add-function around it and insert the closer after
+ ;; all the rest of the hook has run.
+ (if (or (eq syntax ?\")
+ (and (eq syntax ?\))
+ (>= (point) (mark)))
+ (and (not (eq syntax ?\)))
+ (>= (mark) (point))))
+ (save-excursion
+ (goto-char (mark))
+ (electric-pair--insert pair num))
+ (delete-region beg pos)
+ (electric-pair--insert pair num)
+ (goto-char (mark))
+ (electric-pair--insert last-command-event num)))
+ ;; Backslash-escaped: no pairing, no skipping.
+ ((save-excursion
+ (goto-char beg)
+ (not (evenp (skip-syntax-backward "\\"))))
+ (let ((current-prefix-arg (1- num)))
+ (electric-pair-post-self-insert-function)))
+ ;; Skip self.
+ ((and (memq syntax '(?\) ?\" ?\$))
+ (and (or unconditional
+ (if (functionp electric-pair-skip-self)
+ (electric-pair--save-literal-point-excursion
+ (goto-char pos)
+ (funcall electric-pair-skip-self
+ last-command-event))
+ electric-pair-skip-self))
+ (save-excursion
+ (when (and
+ (not (and unconditional (eq syntax ?\")))
+ (setq skip-whitespace-info
+ (if (and
+ (not
+ (eq electric-pair-skip-whitespace
+ 'chomp))
+ (functionp electric-pair-skip-whitespace))
+ (funcall electric-pair-skip-whitespace)
+ electric-pair-skip-whitespace)))
+ (funcall electric-pair-skip-whitespace-function))
+ (eq (char-after) last-command-event))))
+ ;; This is too late: rather than insert&delete we'd want to only
+ ;; skip (or insert in overwrite mode). The difference is in what
+ ;; goes in the undo-log and in the intermediate state which might
+ ;; be visible to other post-self-insert-hook. We'll just have to
+ ;; live with it for now.
+ (when skip-whitespace-info
+ (funcall electric-pair-skip-whitespace-function))
+ (delete-region beg (if (eq skip-whitespace-info 'chomp)
+ (point)
+ pos))
+ (forward-char num))
+ ;; Insert matching pair.
+ ;; String pairs
+ ((and (eq syntax 'str) (not overwrite-mode))
+ (if space (insert " "))
+ (save-excursion
+ (insert pair)))
+ ;; Char pairs
+ ((and (memq syntax '(?\( ?\" ?\$))
+ (not overwrite-mode)
+ (or unconditional
+ (not (electric-pair--save-literal-point-excursion
+ (goto-char pos)
+ (funcall electric-pair-inhibit-predicate
+ last-command-event)))))
+ (save-excursion (electric-pair--insert pair num)))))))))
(defun electric-pair-open-newline-between-pairs-psif ()
"Honor `electric-pair-open-newline-between-pairs'.
--
2.50.1 (Apple Git-155)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Andrew Hyatt <ahyatt@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Lars Ingebrigtsen <larsi@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 50236) by debbugs.gnu.org; 24 Aug 2022 10:19:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 24 06:19:48 2022 Received: from localhost ([127.0.0.1]:45696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oQnUC-00069c-9g for submit <at> debbugs.gnu.org; Wed, 24 Aug 2022 06:19:48 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1oQnUB-00069O-E7 for 50236 <at> debbugs.gnu.org; Wed, 24 Aug 2022 06:19:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OJ5YHYufNYoIEo74JZMYc5Wtkdlovax48a7bz/+VKW4=; b=CCxeq1K3tbSCBGxsy/fad56pg8 VOl5c0tWjpwSeDAjcwzsz2roYuXGamFWhoyPSwGChgPuPNQPGReP89wSdmICHa2UKhll4tAVX7eNt gWlxC475zxz6PpFDTgxNVnR+4FMnBaHEOjKo+OJes/7p5uFWloQOL3ZECmMYK8EUT/eE=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1oQnU3-0004Jx-3N; Wed, 24 Aug 2022 12:19:41 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Augusto Stoffel <arstoffel@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <87tu62sxt7.fsf@HIDDEN> (Augusto Stoffel's message of "Tue, 23 Aug 2022 18:56:52 +0200") References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> <87tu62sxt7.fsf@HIDDEN> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUfWT/brS2Abn3g zrX///8fLI/6AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YIGAoHLjcUeFAAAAFxSURBVDjLdZSJtcQg CEWVaUBjA4oNROm/t8/iku0zc+ZErjwQyTg3zAdwcLi3efnJb/+Hawh9w6i+8gr3h62CLeGZAi1w BbA+6ArxkO0rwM8d7Au3zNPCjygR1UbnA1Qa1iE/QJvAItoTNO1QLwXZfWCeUq35KIAIay1X0PVE vVPH2lK9AK0KsddOLe0IMtCZEMWDw+6AM/SOnJz1zL0BIYMSBohLiiWQqzpVKvFhBuAkRKXXc+ZI s6ph+ae1rnL/NWmTdiuIpMQg7rYn/jCopG3Il/vgYgIC8hcWaPM+0GFmGTAlaDOJRGRw+Lpzbgo7 4QYaJ6cTlKDLloNUics8IYMwyCtC9gtgIU4jYyxXm6xai1CVzJt5ENU/gVQ7cmipqdmYQUaZ4rw7 IrPZudHaa8t9KClc1qlXsA64BlyGL+5x57fD20oqLAEuIF5e0v3s3QDewpZWvD/oqaJVO/caL8Pv 4iXDPTa8wNdfzf1kn+APysxK5VK9dhMAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDgtMjRUMTA6 MDc6NDYrMDA6MDCzKa94AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA4LTI0VDEwOjA3OjQ2KzAw OjAwwnQXxAAAAABJRU5ErkJggg== X-Now-Playing: The Flying Lizards's _The Flying Lizards_: "The Window" Date: Wed, 24 Aug 2022 12:19:35 +0200 Message-ID: <87k06yoseg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Augusto Stoffel <arstoffel@HIDDEN> writes: > This makes sense. However, in comint the "input" field has no field > property; only the output is labeled as such. So the suggestion to do > something special if inside a field wouldn't solve the o [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50236 Cc: 50236 <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 (---) Augusto Stoffel <arstoffel@HIDDEN> writes: > This makes sense. However, in comint the "input" field has no field > property; only the output is labeled as such. So the suggestion to do > something special if inside a field wouldn't solve the original problem > described in the bug. Ah, right. > So the conclusion seems to be that a comint-specific > electric-pair-skip-self function is needed (namely, one that narrows to > the current field provided the current field property is nil, to avoid > those performance issues.) The other possible solution (that I mentioned, but didn't expand on) is that we could just fix this in electric-pair without relying on narrow-to-field. That is, once electric-pair has found the matching pair, we just look at the region between the two chars and see whether they are part of the same field. That should be reasonably fast, since electric-pair already limits the range it's willing to search for a pair.
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 23 Aug 2022 16:57:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 23 12:57:04 2022 Received: from localhost ([127.0.0.1]:44926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oQXD5-0000Gg-TP for submit <at> debbugs.gnu.org; Tue, 23 Aug 2022 12:57:04 -0400 Received: from mail-ed1-f49.google.com ([209.85.208.49]:44916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <arstoffel@HIDDEN>) id 1oQXD3-0000G4-Ov for 50236 <at> debbugs.gnu.org; Tue, 23 Aug 2022 12:57:02 -0400 Received: by mail-ed1-f49.google.com with SMTP id t5so18813593edc.11 for <50236 <at> debbugs.gnu.org>; Tue, 23 Aug 2022 09:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc; bh=Q3NfHAmh12KC11+ZCP9Eg0/ptWnWuSlgI2xIUiC4opM=; b=GMl71cxQOPDU4EVL3O0ErxLMIZKMImc2gLRrlmNW3VaCSSFJcVztKub8kSUqwItf4x f6jkOoZnkvcBsu+bPpcQbcEb6UnCH8KW/sfiLLGoLiqn+W9tqJaYnN4C5sgEfILsbQld MnDG/kQXzq/1kLd865hRFp4Ntd9jRFb/E9unamG9eMOguxJKPlA8cSsi2EGQWZEZnlV9 on1+i605XEjm15GfwF3gyB6lRXV+IROWISFC69dQR4Tll0kOuKrFYaJr76Id+NwU472T 5tYS/B7owjkBpBImoH4g1tHjBKWtfHG9MU5BgCkMZS+rpF7lNQA3NT5eHyV/g+onyGm4 jxTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=Q3NfHAmh12KC11+ZCP9Eg0/ptWnWuSlgI2xIUiC4opM=; b=cpc3MJl0L4U27wrQwJt25QGI28uMMANz6Fobvm2DmEIVeKsCJ14Za5cOnMx7UY7T7Q o/QXQ14o5cnvNIXaU0/Jy3myVvm5RSGwPysZgnEH/HngF6yRsKWFzKiNZb+0LrxL3wNr DgJFEOoo2I7hnH2oWplXgTZKlVZ6Y5GiRfUNmIhFV7Wdr/lxgp/UpAWgjTHxiE7sjd+b 38IwrBORyH7jxXvWHySBagYHgDMRrjgqvENVw4lvPKA0oqYwvh33hJBrOkM3WBImsskd DaEkXje0u0CSZKIVS5cas/dyBxRIJwr/ZXiKonyu+blubHHc/j9694ABSvhUSozN8JML Lmug== X-Gm-Message-State: ACgBeo2OWorXYZO2ZtYho4bleE6DdKSB5KxLFggxBCaCtcdvnpqRuBf9 0K31z7jnxUae2knNwX2OiskG8U8oiJE= X-Google-Smtp-Source: AA6agR6xqSOTPeCBY3EPcvVpCnulEu+XL/hktSk3lF1WWTvI5SpvdtfLvrE6hkWZlb1lJgHix6ob2w== X-Received: by 2002:a05:6402:454:b0:447:59a8:fc7d with SMTP id p20-20020a056402045400b0044759a8fc7dmr789301edw.68.1661273815304; Tue, 23 Aug 2022 09:56:55 -0700 (PDT) Received: from ars3 ([2a02:8109:8ac0:56d0::157b]) by smtp.gmail.com with ESMTPSA id b1-20020a1709063ca100b00728f6d4d0d7sm109656ejh.67.2022.08.23.09.56.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 09:56:54 -0700 (PDT) From: Augusto Stoffel <arstoffel@HIDDEN> To: Lars Ingebrigtsen <larsi@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <875yijuvzf.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Tue, 23 Aug 2022 11:53:24 +0200") References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> <875yijuvzf.fsf@HIDDEN> Date: Tue, 23 Aug 2022 18:56:52 +0200 Message-ID: <87tu62sxt7.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50236 Cc: 50236 <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 (-) On Tue, 23 Aug 2022 at 11:53, Lars Ingebrigtsen <larsi@HIDDEN> wrote: > > Augusto Stoffel <arstoffel@HIDDEN> writes: > >>> That would make sense in this case... I'm trying to think of instances >>> where it wouldn't make sense, and I can't think of any. > > [...] > >> So I guess my question here is: does it make sense for a major mode with >> a notion of "code blocks" set field properties as part of the >> font-locking? Or is there any reason not to mix up fields with >> font-locking? > > Hm, that's an interesting question. I think that, basically, the only > usage for the "field" thing is to divide a line up into bits so that > `C-a' takes you to the start of the field instead of the start of the > line. Extending the "field" thing to mark larger blocks is might well > make sense. > > Anyway, this reminds me of a performance problem we have when making > commands field sensitive: It's generally kinda slow. > > It's no problem in the `C-a' case -- we're limited to the current line, > so our search for field properties is very short. I was making some > other command field sensitive (I forget which), but had to abandon it, > because it was too slow. The problem is, generally, that when you're > not in a field, you want to find the end the previous field and delimit > the command to that region. > > However, the previous field may be anywhere, so the searches for the > field text property goes back to point-min. And that's just unworkably > slow for functions that trigger a lot -- and I think that this may be > the case for electric-pair-mode, too. > > I mean -- we could delimit electric-pair-mode to the current field, if > there is one, but we can't do the same if we're not in a field. This makes sense. However, in comint the "input" field has no field property; only the output is labeled as such. So the suggestion to do something special if inside a field wouldn't solve the original problem described in the bug. So the conclusion seems to be that a comint-specific electric-pair-skip-self function is needed (namely, one that narrows to the current field provided the current field property is nil, to avoid those performance issues.)
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Received: (at 50236) by debbugs.gnu.org; 23 Aug 2022 09:53:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 23 05:53:36 2022 Received: from localhost ([127.0.0.1]:42619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oQQbI-0005FQ-Cl for submit <at> debbugs.gnu.org; Tue, 23 Aug 2022 05:53:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1oQQbF-0005FC-IV for 50236 <at> debbugs.gnu.org; Tue, 23 Aug 2022 05:53:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=32avkb2LJzN1cJvYf7bB78XE/+erxGzaZ6SG3HuJX/U=; b=WhIb/hBc2Q0OYVTU1Q75p8Zj+A jlXGIbwiabEhtv1GYpLzO8YIGjhFMY9AhbT9SSIsOC8fBBoE2tZjEVyU3mL1h91B/OS7/O9KaE1W7 1dQu7eo3HnOHDcociwSb0WgD8LOEWSq/6gWPWd7rvM6Fd8gWDNU+7cz0qBnHGlzY1XxU=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1oQQb7-00079N-2Q; Tue, 23 Aug 2022 11:53:27 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Augusto Stoffel <arstoffel@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <87v8qk5kit.fsf@HIDDEN> (Augusto Stoffel's message of "Mon, 22 Aug 2022 18:07:54 +0200") References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> <87tu642sso.fsf@HIDDEN> <87v8qk5kit.fsf@HIDDEN> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUzGBdPKiJtTD+f emP///+YbcQvAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YIFwkHALHn25AAAAGQSURBVDjLbZTbdcAg CEAlXQDIAgEXaGT/3QqiiUnKjx4vD3loKSFAiFC+QgEoVXA5r0YpEiCRq4H+7n5YAOzAsKAjQTGu tbHaVptqVbWTpYNqZq2Z1b1Z31utCarvm+0GvgmNVrX4HcGAqHmUHQEEaCMPExZ78zRc8MfcP1Hm E678KiRxr2qihDcoaRHInYwEaSyLJIEvKAuAj8FwlUewWMBcLhtEfAdnSdKPYAnOZ5zOGAvYzxF8 bZXrdwu5ol+ZVwfMOmPcrgLQAhYLLyArf10pbhIWD1CIN+9386YLPWMgn2a935iZDABsvzEHpoY5 c7O6bGcHZlIewbWmK3eW+lkxhqY2RfEqOwj6CKa+K5w3OBRa0yYdVlkadRTulVf1RNYEs4Fy9xaW uRJSVmF51gqnI34XMUTlDcYAuYW+qjs99RhrEZlF+zPzlsgcBowpogDsPXHQtaHktPR58yyF7q7j iIJjFpHyNcXidqQk0iuSgAotqfjU+VPrY4rX5wF97zW46rS8FChLcv/8Rh38AdXYQFTLI7H7AAAA JXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA4LTIzVDA5OjA3OjAwKzAwOjAws9CHUwAAACV0RVh0ZGF0 ZTptb2RpZnkAMjAyMi0wOC0yM1QwOTowNzowMCswMDowMMKNP+8AAAAASUVORK5CYII= X-Now-Playing: Fairport Convention's _Come All Ye (6)_: "Dirty Linen" Date: Tue, 23 Aug 2022 11:53:24 +0200 Message-ID: <875yijuvzf.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Augusto Stoffel <arstoffel@HIDDEN> writes: >> That would make sense in this case... I'm trying to think of instances >> where it wouldn't make sense, and I can't think of any. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50236 Cc: 50236 <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 (---) Augusto Stoffel <arstoffel@HIDDEN> writes: >> That would make sense in this case... I'm trying to think of instances >> where it wouldn't make sense, and I can't think of any. [...] > So I guess my question here is: does it make sense for a major mode with > a notion of "code blocks" set field properties as part of the > font-locking? Or is there any reason not to mix up fields with > font-locking? Hm, that's an interesting question. I think that, basically, the only usage for the "field" thing is to divide a line up into bits so that `C-a' takes you to the start of the field instead of the start of the line. Extending the "field" thing to mark larger blocks is might well make sense. Anyway, this reminds me of a performance problem we have when making commands field sensitive: It's generally kinda slow. It's no problem in the `C-a' case -- we're limited to the current line, so our search for field properties is very short. I was making some other command field sensitive (I forget which), but had to abandon it, because it was too slow. The problem is, generally, that when you're not in a field, you want to find the end the previous field and delimit the command to that region. However, the previous field may be anywhere, so the searches for the field text property goes back to point-min. And that's just unworkably slow for functions that trigger a lot -- and I think that this may be the case for electric-pair-mode, too. I mean -- we could delimit electric-pair-mode to the current field, if there is one, but we can't do the same if we're not in a field. So if you have --- *Here's a field with (* Here we, much later in the buffer, are outside of a field and we type ) --- we can't (for these performance reasons) just use a `narrow-to-field' first when checking whether that ) matches that other (. Once we have the pairs, we could check whether both are in the same field, though.
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
Received: (at 50236) by debbugs.gnu.org; 22 Aug 2022 16:08:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 22 12:08:09 2022
Received: from localhost ([127.0.0.1]:41572 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oQ9yD-0000to-2L
for submit <at> debbugs.gnu.org; Mon, 22 Aug 2022 12:08:09 -0400
Received: from mail-ej1-f53.google.com ([209.85.218.53]:42895)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <arstoffel@HIDDEN>) id 1oQ9y9-0000tJ-5G
for 50236 <at> debbugs.gnu.org; Mon, 22 Aug 2022 12:08:07 -0400
Received: by mail-ej1-f53.google.com with SMTP id ca13so10897456ejb.9
for <50236 <at> debbugs.gnu.org>; Mon, 22 Aug 2022 09:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc;
bh=Z/wwgsRl8UdoJkwKXheko/goIyjQzxAk8YmAWUGVZgY=;
b=HEe60dCxdBso6ULb/9hAjvrfhU3G4UR3HvAR29LzZsNegGUsvZMxBLShm8UDAkHTnQ
znxWPTC2pSeAHdhcqg3TuJfjVSd5xaqOnUELNzg/p0KABHHtAOY/oSksqvaJ9d5wtsFd
QdQ/rvJivfUsYc0brFepsP2XQilHB5SXCGModza0GvIt/7gZCed8eQtAtMWd4VneQFC0
E187Eml9aEInPXYGW9be0BZL7RMDoHrraF7hccDVSf7v5rbFD/oXHt5ENmANAvYGTNMQ
t3oBwqPitnKY2hWZ7yR2IjeKQrgtoUBBuXEXYSKvx+vZ81bYJorgnxLoNSAwvW1OP3O9
da4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc;
bh=Z/wwgsRl8UdoJkwKXheko/goIyjQzxAk8YmAWUGVZgY=;
b=wI7cm70enGKzVzhoPd48Sbpsj4G4XI5WMB/eDy6t2wSHdCt5WjFJ3IdhQI+7T1ySVF
wwkATQp8ar+mtQk43M75SmpQ7DrOoHMCmQjLl+jeOVJtjtQmJnGDs5VUxiNnhPzwKnkW
qLfFGLLYxtKokHdRuU9EWAOSy0gf5KCcIRDIGX8XHO4wwOYySrFjABxvgZ2Jp4q6yyvE
DmejBH07K17gRpy/QotR+oZxl77fF29WWh0GoX/cseYXPMRnb9/rxqo08EbPqThc1u40
JJbB06UGix7wx911OuwE+FY/6hAHvl2Wkp2x+9r65XT2Ug9CoVBNWMHrpwJNTjq/Shej
oFrg==
X-Gm-Message-State: ACgBeo2MaOYmTKD09h1XT8dORrijL9zIIyo5gHfx8moVVhRp9cDZ94hH
A23ZovLdwCGVVq9ZlkaOsnK7AlqD5Sk=
X-Google-Smtp-Source: AA6agR4ugMdsFEQ6JLeUY52clhmEZYthrgfCYZXbKWI4bTGaj/xPTkphAR4f0YjMA1mNrKEhu1yIQg==
X-Received: by 2002:a17:907:75e8:b0:73d:53dc:661d with SMTP id
jz8-20020a17090775e800b0073d53dc661dmr9547497ejc.738.1661184478034;
Mon, 22 Aug 2022 09:07:58 -0700 (PDT)
Received: from ars3 ([2a02:8109:8ac0:56d0::157b])
by smtp.gmail.com with ESMTPSA id
o21-20020a170906769500b0073d685a2985sm3370063ejm.108.2022.08.22.09.07.55
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 22 Aug 2022 09:07:56 -0700 (PDT)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint
In-Reply-To: <87tu642sso.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Mon,
22 Aug 2022 17:37:27 +0200")
References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN>
<87tu642sso.fsf@HIDDEN>
Date: Mon, 22 Aug 2022 18:07:54 +0200
Message-ID: <87v8qk5kit.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 50236
Cc: 50236 <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 (-)
On Mon, 22 Aug 2022 at 17:37, Lars Ingebrigtsen <larsi@HIDDEN> wrote:
>
> Augusto Stoffel <arstoffel@HIDDEN> writes:
>
>> The following quick fix works for me:
>>
>> (defun electric-pair-skip-in-field (char)
>> (save-restriction
>> (narrow-to-region (field-beginning) (field-end))
>> (electric-pair-default-skip-self char)))
>>
>> (add-hook 'comint-mode-hook (lambda () (setq-local electric-pair-skip-self
>> 'electric-pair-skip-in-field)))
>>
>> Perhaps `electric-pair-default-skip-self' should always narrow to the
>> current field?
>
> That would make sense in this case... I'm trying to think of instances
> where it wouldn't make sense, and I can't think of any.
There's a second question of relevance here: would this change help
solving similar bugs in other modes? Consider for instance an Org file
like this
(
#+begin_src
f(<type close parens here>)
#+end_src
or a Markdown file like this
(
```
f(<type close parens here>)
```
Of course each of these modes could define their own
electric-pair-skip-self, but ideally a general mechanism to deal with
this situation should we provided.
So I guess my question here is: does it make sense for a major mode with
a notion of "code blocks" set field properties as part of the
font-locking? Or is there any reason not to mix up fields with
font-locking?
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.Lars Ingebrigtsen <larsi@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 50236) by debbugs.gnu.org; 22 Aug 2022 15:37:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 22 11:37:40 2022 Received: from localhost ([127.0.0.1]:41517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oQ9Uh-0006JL-SW for submit <at> debbugs.gnu.org; Mon, 22 Aug 2022 11:37:40 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1oQ9Uf-0006J5-PB for 50236 <at> debbugs.gnu.org; Mon, 22 Aug 2022 11:37:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Db1lF7VO8u+tUh5aRSuu6n+BTNVHn450qaGm7DyanK4=; b=CW0arKxIUULAxWsLfj4zJdZZ4E vICd6Vr3y2wO6ULlbsjlq+Nrz+nXqPKY2cMqU9tAcBLpbvvPaPLRx16aVlkWvj6hhlpzRNwTxmQeM Nm6cDB8rc39loLNqYXV1Adj/XnQQOQHJK7oaPJwu+TT9JmyO7P2r1akffboASdRDPRBw=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1oQ9UX-0006yW-K5; Mon, 22 Aug 2022 17:37:31 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Augusto Stoffel <arstoffel@HIDDEN> Subject: Re: bug#50236: 27.2; electric-pair-mode is inconvenient in comint In-Reply-To: <87zgn4nxv7.fsf@HIDDEN> (Augusto Stoffel's message of "Sun, 06 Feb 2022 10:33:00 +0100") References: <87bl5heuva.fsf@HIDDEN> <87zgn4nxv7.fsf@HIDDEN> X-Now-Playing: Fieh's _Blue Note Re:imagined (2)_: "Armageddon" Date: Mon, 22 Aug 2022 17:37:27 +0200 Message-ID: <87tu642sso.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Augusto Stoffel <arstoffel@HIDDEN> writes: > The following quick fix works for me: > > (defun electric-pair-skip-in-field (char) > (save-restriction > (narrow-to-region (field-beginning) (field-end)) > (electric-pair-default-skip-self char))) [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50236 Cc: 50236 <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 (---) Augusto Stoffel <arstoffel@HIDDEN> writes: > The following quick fix works for me: > > (defun electric-pair-skip-in-field (char) > (save-restriction > (narrow-to-region (field-beginning) (field-end)) > (electric-pair-default-skip-self char))) > > (add-hook 'comint-mode-hook (lambda () (setq-local electric-pair-skip-self > 'electric-pair-skip-in-field))) > > Perhaps `electric-pair-default-skip-self' should always narrow to the > current field? That would make sense in this case... I'm trying to think of instances where it wouldn't make sense, and I can't think of any. So perhaps we should make this change in general? Anybody have any opinions here?
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Feb 2022 09:33:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 06 04:33:22 2022
Received: from localhost ([127.0.0.1]:36431 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGdv7-00054r-Ux
for submit <at> debbugs.gnu.org; Sun, 06 Feb 2022 04:33:22 -0500
Received: from lists.gnu.org ([209.51.188.17]:44392)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <arstoffel@HIDDEN>) id 1nGdv6-00054k-2x
for submit <at> debbugs.gnu.org; Sun, 06 Feb 2022 04:33:20 -0500
Received: from eggs.gnu.org ([209.51.188.92]:43504)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
id 1nGdv4-0004Bm-QQ
for bug-gnu-emacs@HIDDEN; Sun, 06 Feb 2022 04:33:19 -0500
Received: from [2a00:1450:4864:20::535] (port=41525
helo=mail-ed1-x535.google.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
id 1nGdv2-0002st-VE
for bug-gnu-emacs@HIDDEN; Sun, 06 Feb 2022 04:33:18 -0500
Received: by mail-ed1-x535.google.com with SMTP id cz16so5211884edb.8
for <bug-gnu-emacs@HIDDEN>; Sun, 06 Feb 2022 01:33:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:to:subject:references:date:in-reply-to:message-id:user-agent
:mime-version:content-transfer-encoding;
bh=pptVrnnMh3L4ziTlDgWtpfBsJZCnxH5iXF4w0kLy/gs=;
b=NliaF/wx83KHwuWQloA/cVoWT/jQ9bGPXF9nhaEqlK1Ha1z+uZ1LcD3wd7feYxUpK4
ITcyoS0OGPmm8pB5GcspW+XoH2oDNDIe/Kfoe1O+rMpbx3+2qRM5GZq3sFXNsU4ijiYj
zSgbpfNRZNhwsJQ5dYsdU3Wo++flvQO4FNpdSlUdS3S+HIwUTEAnv7+dSNywYWbdEBy8
w0uV+AwkQQ7TYQNjZXiEt70jTXyOu2BCBLNmEbCK52NWtVLosL85DcVa/Rs7RJEZFPJz
L8IAsZcCjwhqmxElNMDJlE5rTHYPMX6TU/PjTCFIBHH36Byr0QOUUyRyBs1mhKRsIxl5
gElA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=pptVrnnMh3L4ziTlDgWtpfBsJZCnxH5iXF4w0kLy/gs=;
b=BnTzv/Anoy3Iqf7OClIO+R0Kq9EwjGjrUgfFhpSmZdZvVTM7tZEE1zIQ23NBdxyJWB
93rZOsOU174HUYw8J7vMuzMfhL/iOmRhT4vQmbQAcCkLCB4buNXdBfQScmoLCG2Y1skt
NJ+n/2O0eUYBKhbHHG/mpdHXIowy5gNqKegKFRiQ353aKKF1D2WNXuAEXnnIim7ZzeRV
3f0xk7uUqrk6EJNJZQ5vsQC18Hq9naN2Zx/qdOP1lsoYrHYPLgWRUNBIxsVr3Z51KwNO
JoWvrj4FEB4bMfba9QhEXH+jMIYLbglpTwL8ZOMx5aCNWAZaVpVyyp+R+7rRtHYyXWPr
otKw==
X-Gm-Message-State: AOAM531L9FoGvAK2lkaBS62eURxtfjS7caEPueuyqr9SCEVQ0QnKTdZC
rPMmiOMpIlHXrSy419fo+8xFPUD4M/g=
X-Google-Smtp-Source: ABdhPJz0wKvP4PA3NutHxC47ajEvbsV4BKdJtp2utfCk7JpLlwweIs3eEGJ8tL+ZPXTchHVsMx96rQ==
X-Received: by 2002:a05:6402:348b:: with SMTP id
v11mr8068655edc.58.1644139981769;
Sun, 06 Feb 2022 01:33:01 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::a4e1])
by smtp.gmail.com with ESMTPSA id j11sm607365ejb.110.2022.02.06.01.33.00
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 06 Feb 2022 01:33:01 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Re: 27.2; electric-pair-mode is inconvenient in comint
References: <87bl5heuva.fsf@HIDDEN>
Date: Sun, 06 Feb 2022 10:33:00 +0100
In-Reply-To: <87bl5heuva.fsf@HIDDEN> (Augusto Stoffel's message of "Sat, 28
Aug 2021 12:17:29 +0200")
Message-ID: <87zgn4nxv7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::535
(failed)
Received-SPF: pass client-ip=2a00:1450:4864:20::535;
envelope-from=arstoffel@HIDDEN; helo=mail-ed1-x535.google.com
X-Spam_score_int: -12
X-Spam_score: -1.3
X-Spam_bar: -
X-Spam_report: (-1.3 / 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,
PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
The following quick fix works for me:
(defun electric-pair-skip-in-field (char)
(save-restriction
(narrow-to-region (field-beginning) (field-end))
(electric-pair-default-skip-self char)))
(add-hook 'comint-mode-hook (lambda () (setq-local electric-pair-skip-s=
elf
'electric-pair-skip-=
in-field)))
Perhaps `electric-pair-default-skip-self' should always narrow to the
current field?
There are a few more situations where electric-pair-mode looks to far;
for instance, when inside an org src block, mismatched parenthesis
outside the block shouldn't matter. So maybe an even more general
solution is in order.
On Sat, 28 Aug 2021 at 12:17, Augusto Stoffel <arstoffel@HIDDEN> wrote:
> In comint buffers, electric pair mode should only look at the current
> input region to decide whether to skip over a closing bracket or add a
> new one. Otherwise, it gets confused about mismatched delimiters in
> previous inputs or outputs.
>
> To give an example, if I enter, in a fresh shell
>
> X=3D'('
>
> at the first prompt, and then type =E2=80=9C())=E2=80=9D in the second pr=
ompt, I get
> the following sequence of states (where | indicates the point)
>
> |
> (|)
> ()|)
> ())|
>
> where I would instead expect the obvious:
>
> |
> (|)
> ()|
> ())|
bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 Aug 2021 10:17:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 28 06:17:35 2021
Received: from localhost ([127.0.0.1]:53440 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mJvP5-0002ET-1G
for submit <at> debbugs.gnu.org; Sat, 28 Aug 2021 06:17:35 -0400
Received: from lists.gnu.org ([209.51.188.17]:52630)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <arstoffel@HIDDEN>) id 1mJvP3-0002EK-Gd
for submit <at> debbugs.gnu.org; Sat, 28 Aug 2021 06:17:33 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50150)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
id 1mJvP3-0005CR-BA
for bug-gnu-emacs@HIDDEN; Sat, 28 Aug 2021 06:17:33 -0400
Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:51765)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
id 1mJvP1-0008Fu-Un
for bug-gnu-emacs@HIDDEN; Sat, 28 Aug 2021 06:17:33 -0400
Received: by mail-wm1-x332.google.com with SMTP id u15so5415868wmj.1
for <bug-gnu-emacs@HIDDEN>; Sat, 28 Aug 2021 03:17:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:date:message-id:mime-version
:content-transfer-encoding;
bh=5UKuD5fl1PBkHdppd4VblTR8gqfIBQyXIIjI8L5/aTI=;
b=spxL3KWLWUHXgeC/7zcECan3Pgiqo7wdQTLo7L9VjvBPe4UFbmg0PSHdDbZ6U+3+NP
bfysjXll65lcyRTUWig1Z1qYgZTXzfb1QVrOpkOVeTXqCWIt+v1AZhYQqABQSKyZYPCS
kQQEDxIX/NaqgglR6b+0Axf+Ey1r+CEAOmpGi+9Yc+Xu9zNx6vsxCZv5uCWljOzKAUo3
wG+NZUlovIb6UHor0itFRTIf6VUDmekUBg/k13LpOQ3hhTPEnLoPngMXLn0G9xCY284O
CO6vAiXPopD/vFcstI9Wm/9A3tDJCfzgL3JI8iHPCG4KjuD2m0175XWjFTFhIj6jqyjD
bRWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:date:message-id:mime-version
:content-transfer-encoding;
bh=5UKuD5fl1PBkHdppd4VblTR8gqfIBQyXIIjI8L5/aTI=;
b=FauxpUdHDXpau4OIa5y5jO68ISO8OyXe4wbEt8IXkC03PiR6IlYMiHfQeuMGU9lj9J
oN57ZHZqqVCDh7CHU64PFS8NNesGdY3pk3pxsOVQHSf8NPpm1uZtf2ZKLwECLtUfUvTa
62dmpii9z5iNdEFAC92or1nqNWXSAnYwjq8oNRYOXiS4Nz9cctrrD3eqNTEbYYnxXoA3
ae+HZnGo9lsP4kU3jm17aChKQ+bdFv07mTvUb5qGwpzU8czHv6x+6HmbZgt6pCXU/dKu
Z/KV57P37TghqayAWDomb/cKhRgz/4CJ3XgTcPlaSxZfUs74dOlkbDMo32kkSiQuXprK
MFfQ==
X-Gm-Message-State: AOAM533VfpjziHFM+929vmGMKsIfYek0rtYADReRFsrUa7YR8CF23tKA
MkFNqjA3hCCrl+7gAIc7IX10bzplxCoCjg==
X-Google-Smtp-Source: ABdhPJwH0sS3Q6pJ4hgIlI60SVWQ24varDjpbghXQSrlbCgs1HDQVX6n+Q0q7k8QBwawxGs4586A7w==
X-Received: by 2002:a1c:e90a:: with SMTP id q10mr24012427wmc.39.1630145850255;
Sat, 28 Aug 2021 03:17:30 -0700 (PDT)
Received: from ars3 ([2a02:8109:8ac0:56d0::ae3f])
by smtp.gmail.com with ESMTPSA id v28sm8974453wrv.93.2021.08.28.03.17.29
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 28 Aug 2021 03:17:29 -0700 (PDT)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.2; electric-pair-mode is inconvenient in comint
Date: Sat, 28 Aug 2021 12:17:29 +0200
Message-ID: <87bl5heuva.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::332;
envelope-from=arstoffel@HIDDEN; helo=mail-wm1-x332.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
In comint buffers, electric pair mode should only look at the current
input region to decide whether to skip over a closing bracket or add a
new one. Otherwise, it gets confused about mismatched delimiters in
previous inputs or outputs.
To give an example, if I enter, in a fresh shell
X=3D'('
at the first prompt, and then type =E2=80=9C())=E2=80=9D in the second prom=
pt, I get
the following sequence of states (where | indicates the point)
|
(|)
()|)
())|
where I would instead expect the obvious:
|
(|)
()|
())|
Augusto Stoffel <arstoffel@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#50236; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.