bug#50236: 27.2; electric-pair-mode is inconvenient in comint

João Távora <[email protected]> Mon, 3 Aug 2026 10:36:49 +0100
Newsgroups gmane.emacs.bugs
Message-ID <CALDnm51D8vExcstbKEGPNdxgtpMQXc_eNg8MqMDiu+Xo9caLqg@mail.gmail.com>
--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 <[email protected]> wrote:

> Eli Zaretskii <[email protected]> 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 <[email protected]> Cc: Ihor Radchenko <
>>> [email protected]>, Lars Ingebrigtsen <[email protected]>,
>>> [email protected], [email protected], [email protected] Date: Sun, 19
>>> Jul 2026 17:28:18 -0400
>>>
>>> Augusto Stoffel <[email protected]> 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 <[email protected]> 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&#39;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&#39;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 &lt;<a href=3D"mailto:[email protected]">ahyatt@gmail=
.com</a>&gt; 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 &lt;<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"=
noreferrer">[email protected]</a>&gt; 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&#39;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 &lt;<a href=3D"mailto:[email protected]" target=3D"_=
blank" rel=3D"noreferrer">[email protected]</a>&gt;
Cc: Ihor Radchenko &lt;<a href=3D"mailto:[email protected]" target=3D"_bl=
ank" rel=3D"noreferrer">[email protected]</a>&gt;,  Lars Ingebrigtsen
&lt;<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">=
[email protected]</a>&gt;,  <a href=3D"mailto:[email protected]" target=3D=
"_blank" rel=3D"noreferrer">[email protected]</a>,  <a href=3D"mailto:j=
[email protected]" target=3D"_blank" rel=3D"noreferrer">joaotavora@gmail.=
com</a>,
<a href=3D"mailto:[email protected]" 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 &lt;<a href=3D"mailto:[email protected]" target=3D"_=
blank" rel=3D"noreferrer">[email protected]</a>&gt; 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&#39;t skip-self for avoiding two closing parens in a row? This doe=
sn&#39;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&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:[email protected]" target=3D"_=
blank" rel=3D"noreferrer">[email protected]</a>&gt; 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&#39;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&#39;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--