GNU bug report logs - #50236
27.2; electric-pair-mode is inconvenient in comint

Previous Next

Full log

View this message in rfc822 format

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50236 <at> debbugs.gnu.org
Subject: bug#50236: 27.2; electric-pair-mode is inconvenient in comint
Date: Tue, 23 Aug 2022 18:56:52 +0200

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

>
> Augusto Stoffel <arstoffel <at> 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.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.