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

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

> Ihor Radchenko <[email protected]> writes:
>> Paragraphs was just an example. My point is - major mode needs to decide
>> such things. And fields often serve different purposes, so, IMHO, they
>> are not the best vehicle to decide about bracket balancing.
>
> What purposes do fields often serve?  I've seen them in comint-based
> shells, widgets, etc.  They don't "decide" about bracket in the same way
> that don't don't "decide" about movement.  This is just about isolating
> operation of certain features (delimiter balancing, movement, etc) to a
> given region.  The uses I've seen of fields all match perfectly.

IMHO, fields are more suitable to mark short spans of the text within
limited region in buffer. (e.g. tables).

> If you'd rather make a complicated setting of electric-pair-skip-self
> and electric-pair-inhibit-predicate etc in your major mode (like c-mode
> infamously did and c-ts-mode fortunately didn't), you can.  I just
> happen to think that setting a continugous 'field' property in your text
> source blocks is a nice thing to do for your users.  But I don't use
> much org.

In Org's case, we would need to fill the whole buffer with
fields. Consider

* I am a heading

(This is some text

* I am another heading

(Here, we do not care about previous section brackets)

#+begin_src emacs-lisp
(message "And here we can Elisp code, that should be isolated")
#+end_src

Marking every single span of text in buffer as field would be heavy.
That's why I mentioned paragraph, thinking about things like
fill-forward-paragraph-function or paragraph-start.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>