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

Eli Zaretskii <[email protected]> Sat, 01 Aug 2026 11:50:00 +0300
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
Ping!  Any further comments or suggestions?

> 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ã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 <[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 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.