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

--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 <[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 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 <[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 =
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 &lt;<a hre=
f=3D"mailto:[email protected]">[email protected]</a>&gt; 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&#39;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&#39;t use fields in=
 some strange way, it should be OK.=C2=A0 I haven&#39;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&#39;s where I saw the discussion headed) is there a manual or =
example to follow?</div></div></blockquote><div><br></div><div>I don&#39;t =
think there&#39;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 &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">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]" rel=3D"noreferrer" target=
=3D"_blank">[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]" rel=3D"nore=
ferrer" target=3D"_blank">[email protected]</a>&gt;
Cc: Ihor Radchenko &lt;<a href=3D"mailto:[email protected]" rel=3D"norefe=
rrer" target=3D"_blank">[email protected]</a>&gt;,  Lars Ingebrigtsen
&lt;<a href=3D"mailto:[email protected]" rel=3D"noreferrer" target=3D"_blank">=
[email protected]</a>&gt;,  <a href=3D"mailto:[email protected]" rel=3D"no=
referrer" target=3D"_blank">[email protected]</a>,  <a href=3D"mailto:j=
[email protected]" rel=3D"noreferrer" target=3D"_blank">joaotavora@gmail.=
com</a>,
<a href=3D"mailto:[email protected]" 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 &lt;<a href=3D"mailto:[email protected]" rel=3D"nore=
ferrer" target=3D"_blank">[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]" rel=3D"nore=
ferrer" target=3D"_blank">[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>
</blockquote></div></div>

--0000000000001e376106583829c8--