bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Marc Soda]

[-- Attachment #1.1: Type: text/plain, Size: 1407 bytes --]

When using electric-pair-mode, electric-pair-conservative-inhibit
doesn't respect electric-pair-preserve-balance. For example, type out a
string, go to the beginning of the line, type ", go to the end of the
line, and type ". You are left with "foo"". (Exact keys from the start
of a line are fooC-a"C-e", if that's more clear.) I would expect to be
left with "foo" instead.

This is easy to resolve in your init file (after some digging), but I
think the current behavior is non-intuitive.

Please consider the attached patch.

In GNU Emacs 29.4 (build 2, x86_64-apple-darwin23.6.0, NS appkit-2487.70
Version 14.6.1 (Build 23G93)) of 2024-10-03 built on gemini.local
Windowing system distributor 'Apple', version 10.3.2566
System Description: macOS 15.0.1

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs-plus@29/29.4/share/info/emacs
--prefix=/usr/local/Cellar/emacs-plus@29/29.4 --with-xml2 --with-gnutls
--with-native-compilation --without-compress-install --without-dbus
--without-imagemagick --with-modules --with-rsvg --with-ns
--disable-ns-self-contained 'CFLAGS=-O2 -DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT -I/usr/local/opt/gcc/include
-I/usr/local/opt/libgccjit/include' 'LDFLAGS=-L/usr/local/lib/gcc/14
-I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include''

[-- Attachment #1.2: Type: text/html, Size: 2548 bytes --]

[-- Attachment #2: 0001-preserve-balance-in-conservative-mode.patch --]
[-- Type: application/octet-stream, Size: 1012 bytes --]

From 7b75b4d1447157fac733c6a1bf23b5e4b7362a65 Mon Sep 17 00:00:00 2001
From: Marc Soda <marc@soda.fm>
Date: Mon, 7 Oct 2024 22:54:33 -0400
Subject: [PATCH] preserve balance in conservative mode

---
 lisp/elec-pair.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
index c9627763d8d..382307503e8 100644
--- a/lisp/elec-pair.el
+++ b/lisp/elec-pair.el
@@ -200,7 +200,11 @@ be considered.")
    (and (eq char (char-before))
 	(eq char (char-before (1- (point)))))
    ;; I also find it often preferable not to pair next to a word.
-   (eq (char-syntax (following-char)) ?w)))
+   (eq (char-syntax (following-char)) ?w)
+   (eq (char-syntax (following-char)) ?w)
+   ;; Also consider preserving balance
+   (and electric-pair-preserve-balance
+        (electric-pair-inhibit-if-helps-balance char))))
 
 (defmacro electric-pair--with-syntax (string-or-comment &rest body)
   "Run BODY with appropriate syntax table active.
-- 
2.39.5 (Apple Git-154)

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Eli Zaretskii]

> Date: Tue, 08 Oct 2024 03:10:54 +0000
> From: Marc Soda <marc@soda.fm>
> 
> When using electric-pair-mode, electric-pair-conservative-inhibit
> doesn't respect electric-pair-preserve-balance. For example, type out a
> string, go to the beginning of the line, type ", go to the end of the
> line, and type ". You are left with "foo"". (Exact keys from the start
> of a line are fooC-a"C-e", if that's more clear.) I would expect to be
> left with "foo" instead.
> 
> This is easy to resolve in your init file (after some digging), but I
> think the current behavior is non-intuitive.
> 
> Please consider the attached patch.

João, do you have any comments?

> diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
> index c9627763d8d..382307503e8 100644
> --- a/lisp/elec-pair.el
> +++ b/lisp/elec-pair.el
> @@ -200,7 +200,11 @@ be considered.")
>     (and (eq char (char-before))
>  	(eq char (char-before (1- (point)))))
>     ;; I also find it often preferable not to pair next to a word.
> -   (eq (char-syntax (following-char)) ?w)))
> +   (eq (char-syntax (following-char)) ?w)  <<<<<<<<<<<<<<<<<<
> +   (eq (char-syntax (following-char)) ?w)  <<<<<<<<<<<<<<<<<<
> +   ;; Also consider preserving balance
> +   (and electric-pair-preserve-balance
> +        (electric-pair-inhibit-if-helps-balance char))))

Why duplicate lines there?

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Marc Soda]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

That was a silly typo on my part from when I created the patch. Thanks for catching. I attached a clean version.

Marc

On Saturday, October 12th, 2024 at 8:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> 
> 
> > Date: Tue, 08 Oct 2024 03:10:54 +0000
> 
> > From: Marc Soda marc@soda.fm
> > 
> > When using electric-pair-mode, electric-pair-conservative-inhibit
> > doesn't respect electric-pair-preserve-balance. For example, type out a
> > string, go to the beginning of the line, type ", go to the end of the
> > line, and type ". You are left with "foo"". (Exact keys from the start
> > of a line are fooC-a"C-e", if that's more clear.) I would expect to be
> > left with "foo" instead.
> > 
> > This is easy to resolve in your init file (after some digging), but I
> > think the current behavior is non-intuitive.
> > 
> > Please consider the attached patch.
> 
> 
> João, do you have any comments?
> 
> > diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
> > index c9627763d8d..382307503e8 100644
> > --- a/lisp/elec-pair.el
> > +++ b/lisp/elec-pair.el
> > @@ -200,7 +200,11 @@ be considered.")
> > (and (eq char (char-before))
> > (eq char (char-before (1- (point)))))
> > ;; I also find it often preferable not to pair next to a word.
> > - (eq (char-syntax (following-char)) ?w)))
> > + (eq (char-syntax (following-char)) ?w) <<<<<<<<<<<<<<<<<<
> > + (eq (char-syntax (following-char)) ?w) <<<<<<<<<<<<<<<<<<
> > + ;; Also consider preserving balance
> > + (and electric-pair-preserve-balance
> > + (electric-pair-inhibit-if-helps-balance char))))
> 
> 
> Why duplicate lines there?

[-- Attachment #2: 0001-preserve-balance-in-conservative-mode.patch --]
[-- Type: application/octet-stream, Size: 969 bytes --]

From 5883b8f22dac78be1f06e1c2760da2fb6fc8c327 Mon Sep 17 00:00:00 2001
From: Marc Soda <marc@soda.fm>
Date: Sat, 12 Oct 2024 15:44:28 -0400
Subject: [PATCH] preserve balance in conservative mode

---
 lisp/elec-pair.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el
index c9627763d8d..71bc33ead26 100644
--- a/lisp/elec-pair.el
+++ b/lisp/elec-pair.el
@@ -200,7 +200,10 @@ be considered.")
    (and (eq char (char-before))
 	(eq char (char-before (1- (point)))))
    ;; I also find it often preferable not to pair next to a word.
-   (eq (char-syntax (following-char)) ?w)))
+   (eq (char-syntax (following-char)) ?w)
+   ;; Also consider preserving balance
+   (and electric-pair-preserve-balance
+        (electric-pair-inhibit-if-helps-balance char))))
 
 (defmacro electric-pair--with-syntax (string-or-comment &rest body)
   "Run BODY with appropriate syntax table active.
-- 
2.39.5 (Apple Git-154)

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[João Távora]

On Sat, Oct 12, 2024 at 1:21 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Tue, 08 Oct 2024 03:10:54 +0000
> > From: Marc Soda <marc@soda.fm>
> >
> > When using electric-pair-mode, electric-pair-conservative-inhibit
> > doesn't respect electric-pair-preserve-balance. For example, type out a
> > string, go to the beginning of the line, type ", go to the end of the
> > line, and type ". You are left with "foo"". (Exact keys from the start
> > of a line are fooC-a"C-e", if that's more clear.) I would expect to be
> > left with "foo" instead.
> >
> > This is easy to resolve in your init file (after some digging), but I
> > think the current behavior is non-intuitive.
> >
> > Please consider the attached patch.
>
> João, do you have any comments?

This is not reproducible here, but then again this isn't an
Emacs -Q recipe. What major-mode? In my *scratch* buffer, if
I type

   f o o C-a " C-e "

, as Marc seems to suggest, I am left with

  ""foo""

as the contents, which is a balanced situation.  I do not expect
to have:

  "foo"

To get that, I would need to have typed " with the region active.

João

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Marc Soda]

Sorry, this is my first emacs bug report, I should have been more clear.

From emacs -Q:

(electric-pair-mode t)
(setq electric-pair-inhibit-predicate 'electric-pair-conservative-inhibit)

Evaluate those two lines and then type:

f o o C-a " C-e "

and you will be left with "foo""

Marc

On Saturday, October 12th, 2024 at 4:35 PM, João Távora <joaotavora@gmail.com> wrote:

> 
> 
> On Sat, Oct 12, 2024 at 1:21 PM Eli Zaretskii eliz@gnu.org wrote:
> 
> > > Date: Tue, 08 Oct 2024 03:10:54 +0000
> > > From: Marc Soda marc@soda.fm
> > > 
> > > When using electric-pair-mode, electric-pair-conservative-inhibit
> > > doesn't respect electric-pair-preserve-balance. For example, type out a
> > > string, go to the beginning of the line, type ", go to the end of the
> > > line, and type ". You are left with "foo"". (Exact keys from the start
> > > of a line are fooC-a"C-e", if that's more clear.) I would expect to be
> > > left with "foo" instead.
> > > 
> > > This is easy to resolve in your init file (after some digging), but I
> > > think the current behavior is non-intuitive.
> > > 
> > > Please consider the attached patch.
> > 
> > João, do you have any comments?
> 
> 
> This is not reproducible here, but then again this isn't an
> Emacs -Q recipe. What major-mode? In my scratch buffer, if
> I type
> 
> f o o C-a " C-e "
> 
> , as Marc seems to suggest, I am left with
> 
> ""foo""
> 
> as the contents, which is a balanced situation. I do not expect
> to have:
> 
> "foo"
> 
> To get that, I would need to have typed " with the region active.
> 
> João

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[João Távora]

On Sat, Oct 12, 2024 at 9:43 PM Marc Soda <marc@soda.fm> wrote:
>
> Sorry, this is my first emacs bug report, I should have been more clear.
>
> From emacs -Q:
>
> (electric-pair-mode t)
> (setq electric-pair-inhibit-predicate 'electric-pair-conservative-inhibit)

Ah, so this is the (quite) old implementation from Stefan, I think.
I didn't write or know it.  I don't think it's compatible with
balance preservation.

João

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> When using electric-pair-mode, electric-pair-conservative-inhibit
> doesn't respect electric-pair-preserve-balance.

That's a feature.
At least that was for me the main reason to have
`electric-pair-conservative-inhibit`, i.e. so the behavior does not
depend on the global paren balance of the whole buffer (both because it
can be costly to compute and because it can be difficult to predict for
the user).

IOW, why do you use `electric-pair-conservative-inhibit` if you care
about preserving global balance?


        Stefan

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Marc Soda]

> That's a feature.
>
> IOW, why do you use `electric-pair-conservative-inhibit` if you care
> about preserving global balance?

Fair enough. To answer your question, I want the other things you have listed in `electric-pair-conservative-inhibit`. In particular, the line commented "I also find it often preferable not to pair next to a word." is very valuable to me. However, I can solve my issue pretty easily by add something like the following to my init.el:

(setq electric-pair-inhibit-predicate
      ;; Also inhibit if the pair would balanced
      (lambda (char)
        (or (electric-pair-conservative-inhibit char)
            (electric-pair-inhibit-if-helps-balance char))))

The reason I submitted the patch is because is took me several years to get irritated enough to dig in and fix it for myself! :) Also, like I said above, it seemed non-intuitive. Thanks for considering, but feel free to disregard.

Are there any improvements you want made here? Only asking because I currently have the context.

Thanks,
Marc

On Thursday, October 17th, 2024 at 12:48 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> 
> 
> > When using electric-pair-mode, electric-pair-conservative-inhibit
> 
> > doesn't respect electric-pair-preserve-balance.
> 
> 
> That's a feature.
> At least that was for me the main reason to have
> `electric-pair-conservative-inhibit`, i.e. so the behavior does not
> depend on the global paren balance of the whole buffer (both because it
> can be costly to compute and because it can be difficult to predict for
> the user).
> 
> IOW, why do you use `electric-pair-conservative-inhibit` if you care
> about preserving global balance?
> 
> 
> Stefan

bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> IOW, why do you use `electric-pair-conservative-inhibit` if you care
>> about preserving global balance?
>
> Fair enough. To answer your question, I want the other things you have
> listed in `electric-pair-conservative-inhibit`.  In particular, the
> line commented "I also find it often preferable not to pair next to
> a word." is very valuable to me.  However, I can solve my issue pretty
> easily by adding something like the following to my init.el:
>
> (setq electric-pair-inhibit-predicate
>       ;; Also inhibit if the pair would balanced
>       (lambda (char)
>         (or (electric-pair-conservative-inhibit char)
>             (electric-pair-inhibit-if-helps-balance char))))

I see, I think you can get the same result with

    (add-function :before-until electric-pair-inhibit-predicate
                  #'electric-pair-conservative-inhibit)

But maybe it would make sense to add a third value to
`electric-pair-preserve-balance` to get the behavior you describe.

> The reason I submitted the patch is because is took me several years
> to get irritated enough to dig in and fix it for myself! :) Also, like
> I said above, it seemed non-intuitive.  Thanks for considering, but
> feel free to disregard.

Do you have an idea of how/where we could change some of the
documentation to avoid that kind of problem in the future?


        Stefan