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

João Távora <[email protected]> writes:

> 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.

In the effort to get a fix out, I'd agree that we should make the simple
change now (the one I have done), and we can later always substitute it
with something more customizable.  I don't think the customization is
necessary for this bugfix.

>
>>> 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).

I'm not 100% sure that marking org blocks as a field is correct. One
thing I worry about is that marking it as a field implies that cursors
will stop on it when going to the beginning of the line, similar to how
they stop at comint prompts. That probably isn't what the user is
expecting.

I feel like I want something that carries the semantic information of
what a field is representing but not the implication on how it affects
movement.  For now, field is probably good enough, but it'd be good to
eventually move onto something else, or refine the information carried
by a field so that it's possible to make this distinction.

>
> João