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

[Augusto Stoffel <arstoffel@gmail.com>]

On Tue, 23 Aug 2022 at 11:53, Lars Ingebrigtsen <larsi@gnus.org> wrote:

>
> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>>> That would make sense in this case...  I'm trying to think of instances
>>> where it wouldn't make sense, and I can't think of any.
>
> [...]
>
>> So I guess my question here is: does it make sense for a major mode with
>> a notion of "code blocks" set field properties as part of the
>> font-locking?  Or is there any reason not to mix up fields with
>> font-locking?
>
> Hm, that's an interesting question.  I think that, basically, the only
> usage for the "field" thing is to divide a line up into bits so that
> `C-a' takes you to the start of the field instead of the start of the
> line.  Extending the "field" thing to mark larger blocks is might well
> make sense.
>
> Anyway, this reminds me of a performance problem we have when making
> commands field sensitive: It's generally kinda slow.
>
> It's no problem in the `C-a' case -- we're limited to the current line,
> so our search for field properties is very short.  I was making some
> other command field sensitive (I forget which), but had to abandon it,
> because it was too slow.  The problem is, generally, that when you're
> not in a field, you want to find the end the previous field and delimit
> the command to that region.
>
> However, the previous field may be anywhere, so the searches for the
> field text property goes back to point-min.  And that's just unworkably
> slow for functions that trigger a lot -- and I think that this may be
> the case for electric-pair-mode, too.
>
> I mean -- we could delimit electric-pair-mode to the current field, if
> there is one, but we can't do the same if we're not in a field.

This makes sense.  However, in comint the "input" field has no field
property; only the output is labeled as such.  So the suggestion to do
something special if inside a field wouldn't solve the original problem
described in the bug.

So the conclusion seems to be that a comint-specific
electric-pair-skip-self function is needed (namely, one that narrows to
the current field provided the current field property is nil, to avoid
those performance issues.)