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

On Fri,  7 Aug 2026, João Távora wrote:

> On Fri, Aug 7, 2026, 07:36 Augusto Stoffel <[email protected]> wrote:
>
>  > - The value of 1000 could be suitable, but you have to be aware this
>  >   will amount to two new buffer field searches for _every_ insertion in
>  >   the buffer, not just parenthesis.  This is probably "peanuts",
>  >   i.e. not relevant, but you should find some way to measure.  Like how
>  >   many spaces can you type in one minute if you hold down the spacebar
>  >   in an emacs -Q -f electric-pair-mode before&after your change?
>
>  This is my opinion another reason to make the computation of bounds a
>  customizable function (i.e. a defvar-local with function value).
>
> Looks needlessly complicated, why wouldn't a mode just set the buffer local value? 

One can argue for or against hard-coding the use of the 'field' property
for this purpose.  There's nothing "needlessly complicated" here, it's
just the obvious way to implement the non hard-coded version.

> We could set it to 0 by default though and set it non-zero in interesting buffers. 
>
> Or, even better, it shouldn't be very hard to find the spot inside
> e-p-p-s-i-f that
> requires the restriction so it would happen well after some culling
> initial checks, that
> effectively render the performance worries stale.

That's not a bad idea.  One such spot is (funcall electric-pair-skip-self ...).
Another one is where the quotes case is handled, and hopefully that's
all.

>
>  That way we can enable the field search only in comint-mode, while at
>  the same time allowing org-mode, markdown-mode et al. to solve the
>  analogous bug much more simply.
>
> I think Andrew's solution is as simple and elegant as it gets. It
> directly expresses the
> "please e-p-m only do whatever it is you do in this subregion".
>
>  The current implementation would force those modes to add redundant
>  fields properties to the buffer, while a suitable text property
>  indicating a "text field" (such as src-block in Org's mode) is already
>  present.
>
> If org-mode is using "text fields", why doesn't it just use text
> fields? :) i.e if using
> something akin to fields, why doesn't it used the proper text properties to help
> interoperate with other parts of Emacs? That's the Emacs way afaik.

I'm just observing a fact; the text property tracking code blocks in Org
and Markdown mode is called something different from 'field'.  I'm
certainly not going to argue those mode authors did it wrong.

Isn't the Emacs way to provide suitable customization hooks?

In fact, experience shows that variables like electric-pair-skip-self
and electric-pair-skip-whitespace over time "graduate" to accept a
function value, because those hooks end up being necessary somehow.

> João Távora