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

Augusto Stoffel <[email protected]> writes:

> On Sat,  8 Aug 2026, João Távora wrote:
>
>> But _if_ you wanted to do that, you'd be wrong.  You wouldn't need to
>> "fill the whole buffer with field [properties]".  A field is just a
>> region of text with the same ‘field’ property, so if you set a single
>> char's worth of "field=blargh" in the '*' (where you already set an
>> overlay anyway aparently) you have the needed demarcations.  Delete that
>> heading and you magically merge the two fields for free.
>
> What if you change the '*' at BOL to ' *' or '*x' or whatever makes it
> stop being a heading delimiter?

Then I suppose the existing code that already removes the overlay does
the (very simple) job of removing th property no?

> What you're arguing for boils down to precomputing all possible e-p-m
> boundaries and encoding the result in field properties.

Yes, segmenting the buffer in fields according to rules of the major
mode.  That's what this major mode already does.

> I really don't get why you think that's better than moving the field
> search logic to a new function and making the e-p-m boundary search
> function customizable, as in
>
>   (defun e-p-m-self-insert-function ()
>     (let ((bounds (funcall e-p-m-bounds-function)))
>       (with-restriction (car bound) (cdr bounds)
>         <old definition of e-p-m-self-insert-function>)))
>


I didn't realize that was your idea, it isn't bad.  But it _is_ a more
powerful hammer, and I don't reach for those immediatley.  More
importantly that doesn't encourage modes to reuse existing Emacs
structural primitives, which happens to be exactly the idea that e-p-m
is built on (I know, I built it).  So I think having modes lay out out
different fields with the standard 'field property is a good thing.  You
could use it for things other than e-p-m.

In the same way that you _could_ have in e-p-m a fully customizable
structural balance system whose default implementation uses syntax
tables and looks at any arbitrary balancing system.  And you could have
a similar duplicate one in show-paren-mode, check-parens, C-M-*, etc...
(in many ways you already have this forward-sexp-function wrinkle, which
I'm not sure e-p-m respects, or should respect).  But it isn't
necessarily the best idea, and neither is it justified.

> This is dead simple.

Maybe.  But it's not now how I see responsible, maintainable design. In
my opinion there are even simpler ways.  There are many ways to solve
this problem in the immediate.

>> Only here would I do the courtesy of marking that a field, because it
>> comes from another language completely.  You already set a 'src-block'
>> to 't' property there.  I'd put a 'field' as well, and call it a day.
>> It's probably a sub-1-loc patch which I would show if I somehow dared to
>> navigate that petaline code base, but surely you can.
>
> The department of redundancy department would like that a lot.

Ahaha.  Carries some laughs, but doesn't carry much water.  The costs
are minimal and this is probably a half-a-LOC change.  It's the
src-block=t that's redundant.  If the authors had foreseen this and
known about fields they would have used field=src-block instead.  Even
today it could be possible to change src-block=t to field=src-block,
although I doubt it (there's likely a zillion org extensions scanning
for that src-block=t).

João