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.