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

[Lars Ingebrigtsen]

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.  So if
you have

---
*Here's a field with (*


Here we, much later in the buffer, are outside of a field and we type )
---

we can't (for these performance reasons) just use a `narrow-to-field'
first when checking whether that ) matches that other (.  Once we have
the pairs, we could check whether both are in the same field, though.