GNU bug report logs - #79476
30.1; False negative in electric-pair-inhibit-if-helps-balance

Previous Next

To reply to this bug, email your comments to 79476 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Du Bois <dubois <at> valvesoftware.com>
To: "'bug-gnu-emacs <at> gnu.org'" <bug-gnu-emacs <at> gnu.org>
Subject: 30.1; False negative in electric-pair-inhibit-if-helps-balance
Date: Fri, 19 Sep 2025 22:26:44 +0000

Reproduction steps:

$ cat > test.py <<EOF

a = "'"
EOF
$ emacs -Q
C-x C-f test.py
M-x electric-pair-mode

In the following, I'll use | to indicate point.
The current line will be empty
Hit ". The current line will look like "|"
Hit ". The current line will look like ""|
This shows that electric-pair-skip-if-helps-balance is working as expected.

Hit RETURN
Hit C-q ". The current line will look like "|
Hit ". The current line will look like ""|"
Expected: the current line looks like ""|

Diagnosis:

The logic for skip-if-helps and inhibit-if-helps is subtly different.
Both remove the character that the user just typed, and then examine the
parse state.  However:

`skip-if-helps` checks the parse state at `(point)` -- is it inside a
string of the same type as the user's quote char?

`inhibit-if-helps` checks the parse-state at `(point-max)` (modulo any
customizations to electric-pair-string-bound-function).  However, at
`(point-max)` the user's un-terminated quote could have caused all kinds
of havoc.  In the example above, the `a = "'"` makes EOB look like it's in a
`'`-string, rather than a `"`-string.  This causes the false-negative.

Other examples of situations that confuse `inhibit-if-helps`:

```
"|
# a = "'"
```
ppss at EOB still looks like a '-string, because the # is ignored

```
"|
""" " """
```
ppss at EOB looks like it's not in a string


Patch:

A minimal patch is to change inhibit-if-helps to use the same logic as
skip-if-helps:

--- elec-pair.el
+++ elec-pair.el
@@ -467,7 +467,7 @@
                          (t
                           (eq (cdr outermost) pair)))))
                 ((eq syntax ?\")
-                 (electric-pair--inside-string-p char)))))))))
+                 (electric-pair--unbalanced-strings-p char)))))))))
 
 (defun electric-pair-skip-if-helps-balance (char)
   "Return non-nil if skipping CHAR would benefit parentheses' balance.


This would make electric-pair--unbalanced-strings-p entirely unused, so
it could be deleted along with the variable
electric-pair-string-bound-function (which is un-customized by any major
mode in emacs)


Another way is to change the logic of unbalanced-strings-p to check the
parse state at (point) rather than (point-max), by customizing
electric-pair-string-bound-function.


In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.6332)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2
 prefix=/g/rel/install/emacs-30.1'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Python

Minor modes in effect:
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-seq python
rx project byte-opt gv bytecomp byte-compile compat pcase treesit comint
subr-x ansi-osc ring cl-loaddefs cl-lib ansi-color cus-start cus-load
elec-pair rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 86360 11467) (symbols 48 8548 0) (strings 32 23964 1208)
 (string-bytes 1 729777) (vectors 16 13151)
 (vector-slots 8 176946 7166) (floats 8 34 6) (intervals 56 275 0)
 (buffers 992 11))

Message #8 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Du Bois <dubois <at> valvesoftware.com>,
 João Távora <joaotavora <at> gmail.com>
Cc: 79476 <at> debbugs.gnu.org
Subject: Re: bug#79476: 30.1;
 False negative in electric-pair-inhibit-if-helps-balance
Date: Sat, 27 Sep 2025 12:05:06 +0300

> Date: Fri, 19 Sep 2025 22:26:44 +0000
> From:  Paul Du Bois via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Reproduction steps:
> 
> $ cat > test.py <<EOF
> 
> a = "'"
> EOF
> $ emacs -Q
> C-x C-f test.py
> M-x electric-pair-mode
> 
> In the following, I'll use | to indicate point.
> The current line will be empty
> Hit ". The current line will look like "|"
> Hit ". The current line will look like ""|
> This shows that electric-pair-skip-if-helps-balance is working as expected.
> 
> Hit RETURN
> Hit C-q ". The current line will look like "|
> Hit ". The current line will look like ""|"
> Expected: the current line looks like ""|
> 
> Diagnosis:
> 
> The logic for skip-if-helps and inhibit-if-helps is subtly different.
> Both remove the character that the user just typed, and then examine the
> parse state.  However:
> 
> `skip-if-helps` checks the parse state at `(point)` -- is it inside a
> string of the same type as the user's quote char?
> 
> `inhibit-if-helps` checks the parse-state at `(point-max)` (modulo any
> customizations to electric-pair-string-bound-function).  However, at
> `(point-max)` the user's un-terminated quote could have caused all kinds
> of havoc.  In the example above, the `a = "'"` makes EOB look like it's in a
> `'`-string, rather than a `"`-string.  This causes the false-negative.
> 
> Other examples of situations that confuse `inhibit-if-helps`:
> 
> ```
> "|
> # a = "'"
> ```
> ppss at EOB still looks like a '-string, because the # is ignored
> 
> ```
> "|
> """ " """
> ```
> ppss at EOB looks like it's not in a string
> 
> 
> Patch:
> 
> A minimal patch is to change inhibit-if-helps to use the same logic as
> skip-if-helps:
> 
> --- elec-pair.el
> +++ elec-pair.el
> @@ -467,7 +467,7 @@
>                           (t
>                            (eq (cdr outermost) pair)))))
>                  ((eq syntax ?\")
> -                 (electric-pair--inside-string-p char)))))))))
> +                 (electric-pair--unbalanced-strings-p char)))))))))
>  
>  (defun electric-pair-skip-if-helps-balance (char)
>    "Return non-nil if skipping CHAR would benefit parentheses' balance.
> 
> 
> This would make electric-pair--unbalanced-strings-p entirely unused, so
> it could be deleted along with the variable
> electric-pair-string-bound-function (which is un-customized by any major
> mode in emacs)
> 
> 
> Another way is to change the logic of unbalanced-strings-p to check the
> parse state at (point) rather than (point-max), by customizing
> electric-pair-string-bound-function.

Thanks.

João, any comments?

Message #11 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Du Bois <dubois <at> valvesoftware.com>, 79476 <at> debbugs.gnu.org
Subject: Re: bug#79476: 30.1;
 False negative in electric-pair-inhibit-if-helps-balance
Date: Sat, 27 Sep 2025 12:47:45 +0100

[Message part 1 (text/plain, inline)]

Haven't looked at this code in a long time. But Paul seems like you have,
closely. Thanks! Maybe you'd make a good maintainer. Note that I do use the
code daily, and so, I presume, do many others. So be careful...

 Anyway, a lot of tests were made, hope they haven't been disabled (there
was this one time...). If the tests pass the patch (or the other way ribs)
and some more tests can be done that fail now and pass with the patch (thus
demonstrating its usefulness), then I have nothing against said patch.

João



On Sat, Sep 27, 2025, 10:05 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Fri, 19 Sep 2025 22:26:44 +0000
> > From:  Paul Du Bois via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > Reproduction steps:
> >
> > $ cat > test.py <<EOF
> >
> > a = "'"
> > EOF
> > $ emacs -Q
> > C-x C-f test.py
> > M-x electric-pair-mode
> >
> > In the following, I'll use | to indicate point.
> > The current line will be empty
> > Hit ". The current line will look like "|"
> > Hit ". The current line will look like ""|
> > This shows that electric-pair-skip-if-helps-balance is working as
> expected.
> >
> > Hit RETURN
> > Hit C-q ". The current line will look like "|
> > Hit ". The current line will look like ""|"
> > Expected: the current line looks like ""|
> >
> > Diagnosis:
> >
> > The logic for skip-if-helps and inhibit-if-helps is subtly different.
> > Both remove the character that the user just typed, and then examine the
> > parse state.  However:
> >
> > `skip-if-helps` checks the parse state at `(point)` -- is it inside a
> > string of the same type as the user's quote char?
> >
> > `inhibit-if-helps` checks the parse-state at `(point-max)` (modulo any
> > customizations to electric-pair-string-bound-function).  However, at
> > `(point-max)` the user's un-terminated quote could have caused all kinds
> > of havoc.  In the example above, the `a = "'"` makes EOB look like it's
> in a
> > `'`-string, rather than a `"`-string.  This causes the false-negative.
> >
> > Other examples of situations that confuse `inhibit-if-helps`:
> >
> > ```
> > "|
> > # a = "'"
> > ```
> > ppss at EOB still looks like a '-string, because the # is ignored
> >
> > ```
> > "|
> > """ " """
> > ```
> > ppss at EOB looks like it's not in a string
> >
> >
> > Patch:
> >
> > A minimal patch is to change inhibit-if-helps to use the same logic as
> > skip-if-helps:
> >
> > --- elec-pair.el
> > +++ elec-pair.el
> > @@ -467,7 +467,7 @@
> >                           (t
> >                            (eq (cdr outermost) pair)))))
> >                  ((eq syntax ?\")
> > -                 (electric-pair--inside-string-p char)))))))))
> > +                 (electric-pair--unbalanced-strings-p char)))))))))
> >
> >  (defun electric-pair-skip-if-helps-balance (char)
> >    "Return non-nil if skipping CHAR would benefit parentheses' balance.
> >
> >
> > This would make electric-pair--unbalanced-strings-p entirely unused, so
> > it could be deleted along with the variable
> > electric-pair-string-bound-function (which is un-customized by any major
> > mode in emacs)
> >
> >
> > Another way is to change the logic of unbalanced-strings-p to check the
> > parse state at (point) rather than (point-max), by customizing
> > electric-pair-string-bound-function.
>
> Thanks.
>
> João, any comments?
>

[Message part 2 (text/html, inline)]

Message #14 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dubois <at> valvesoftware.com, João Távora
 <joaotavora <at> gmail.com>
Cc: 79476 <at> debbugs.gnu.org
Subject: Re: bug#79476: 30.1;
 False negative in electric-pair-inhibit-if-helps-balance
Date: Sat, 11 Oct 2025 11:40:27 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 27 Sep 2025 12:47:45 +0100
> Cc: Paul Du Bois <dubois <at> valvesoftware.com>, 79476 <at> debbugs.gnu.org
> 
> Haven't looked at this code in a long time. But Paul seems like you have, closely. Thanks! Maybe you'd
> make a good maintainer. Note that I do use the code daily, and so, I presume, do many others. So be
> careful...
> 
>  Anyway, a lot of tests were made, hope they haven't been disabled (there was this one time...). If the tests
> pass the patch (or the other way ribs) and some more tests can be done that fail now and pass with the
> patch (thus demonstrating its usefulness), then I have nothing against said patch.

Unfortunately, the proposed change (btw, the diffs were backwards,
from new to old) fails some of the tests:

  Ran 901 tests, 889 results as expected, 12 unexpected (2025-10-11 11:38:16+0300, 5.800210 sec)

  12 unexpected results:
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-js-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-python-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-ruby-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-3-in-python-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-3-in-ruby-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-4-in-js-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-7-in-c-mode-in-comments
     FAILED  electric-pair-leave-unbalanced-quotes-alone-2-at-point-2-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-2-at-point-4-in-ruby-mode-in-comments
     FAILED  electric-pair-leave-unbalanced-quotes-alone-3-at-point-1-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-at-point-2-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-at-point-4-in-ruby-mode-in-comments

So I don't think we can install this without some additional changes
to fix the regressions it causes.

Message #17 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dubois <at> valvesoftware.com, 79476 <at> debbugs.gnu.org
Subject: Re: bug#79476: 30.1;
 False negative in electric-pair-inhibit-if-helps-balance
Date: Sat, 11 Oct 2025 11:43:16 +0100

[Message part 1 (text/plain, inline)]

On Sat, Oct 11, 2025, 09:40 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Sat, 27 Sep 2025 12:47:45 +0100
> > Cc: Paul Du Bois <dubois <at> valvesoftware.com>, 79476 <at> debbugs.gnu.org
> >
> > Haven't looked at this code in a long time. But Paul seems like you
> have, closely. Thanks! Maybe you'd
> > make a good maintainer. Note that I do use the code daily, and so, I
> presume, do many others. So be
> > careful...
> >
> >  Anyway, a lot of tests were made, hope they haven't been disabled
> (there was this one time...). If the tests
> > pass the patch (or the other way ribs) and some more tests can be done
> that fail now and pass with the
> > patch (thus demonstrating its usefulness), then I have nothing against
> said patch.
>
> Unfortunately, the proposed change (btw, the diffs were backwards,
> from new to old) fails some of the tests:
>
>   Ran 901 tests, 889 results as expected, 12 unexpected (2025-10-11
> 11:38:16+0300, 5.800210 sec)
>
>   12 unexpected results:
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-1-in-js-mode
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-1-in-python-mode
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-1-in-ruby-mode
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-3-in-python-mode-in-comments
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-3-in-ruby-mode-in-comments
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-4-in-js-mode-in-comments
>      FAILED
> electric-pair-inhibit-if-strings-mismatched-at-point-7-in-c-mode-in-comments
>      FAILED
> electric-pair-leave-unbalanced-quotes-alone-2-at-point-2-in-ruby-mode
>      FAILED
> electric-pair-leave-unbalanced-quotes-alone-2-at-point-4-in-ruby-mode-in-comments
>      FAILED
> electric-pair-leave-unbalanced-quotes-alone-3-at-point-1-in-ruby-mode
>      FAILED
> electric-pair-leave-unbalanced-quotes-alone-at-point-2-in-ruby-mode
>      FAILED
> electric-pair-leave-unbalanced-quotes-alone-at-point-4-in-ruby-mode-in-comments
>
> So I don't think we can install this without some additional changes
> to fix the regressions it causes.
>

It could also be the case that the test's expectation have been wrong or
unrealistic for a long time. Please try "ert-describe-test" (or something
like that) in one of those tests. The first one seems good enough. It
should produce some sort of intelligible description of what the test is
trying to assert. Then we can understand if it makes sense or not.

João

>

[Message part 2 (text/html, inline)]

Message #20 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Paul Du Bois <dubois <at> valvesoftware.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "79476 <at> debbugs.gnu.org" <79476 <at> debbugs.gnu.org>
Subject: Re: [External Mail] Re: bug#79476: 30.1; False negative in
 electric-pair-inhibit-if-helps-balance
Date: Sat, 11 Oct 2025 23:52:36 +0100

Paul Du Bois <dubois <at> valvesoftware.com> writes:

> Nice; if I'd like to look at and run the tests, where should I look
> for instructions?

To run them non-interactively, more or less like the CI runs them, use
`make` from the source tree of Emacs, after having built it (to build
emacs there are plenty of instructions out there for doing that)

   make -C test electric-tests

I count about 901 today.  Most of these tests are for elec-pair.el which
you edited.  You can filter just some of them with the SELECTOR env
variable

  make -C test electric-tests SELECTOR='"quotes"'

paying close attention to the quoting, I'm using a combination of single
and double quotes so that Emacs sees the Elisp string "quotes", and not
the unbound symbol quotes.

It could be useful to you to you to run them interactively from within
the Emacs session where you're hacking elec-pair.el.  To do that, find
the file test/lisp/electric-tests.el, and load it with:

   M-x emacs-lisp-byte-compile-and-load

Then you may run tests with M-x ert.  This will read a selector from the
minibuffer.  If you give it 't' it will run all the tests.

A word of caution.  I remember well that electric pair tests are highly
sensitive to the syntax tables of modes and parse-partial-sexp.  This is
how the code I wrote knows whether it is in a balanced or unbalanced
situation to begin with.  So you may see different results depending on
the complexity of your configuration, i.e. the amount of hacking you --
or some package you're using -- applies on those syntax tables.  I
recommend starting with a lean configuration (i.e. not very far from
Emacs -Q) where all the tests pass interactively as well as
non-interactively.

Message #23 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: Paul Du Bois <dubois <at> valvesoftware.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "79476 <at> debbugs.gnu.org" <79476 <at> debbugs.gnu.org>
Subject: Re: [External Mail] Re: bug#79476: 30.1; False negative in
 electric-pair-inhibit-if-helps-balance
Date: Sat, 11 Oct 2025 17:55:43 +0000

[Message part 1 (text/plain, inline)]

Nice; if I'd like to look at and run the tests, where should I look for instructions?

p

On Oct 11, 2025 03:43, João Távora <joaotavora <at> gmail.com> wrote:
On Sat, Oct 11, 2025, 09:40 Eli Zaretskii <eliz <at> gnu.org<mailto:eliz <at> gnu.org>> wrote:
> From: João Távora <joaotavora <at> gmail.com<mailto:joaotavora <at> gmail.com>>
> Date: Sat, 27 Sep 2025 12:47:45 +0100
> Cc: Paul Du Bois <dubois <at> valvesoftware.com<mailto:dubois <at> valvesoftware.com>>, 79476 <at> debbugs.gnu.org<mailto:79476 <at> debbugs.gnu.org>
>
> Haven't looked at this code in a long time. But Paul seems like you have, closely. Thanks! Maybe you'd
> make a good maintainer. Note that I do use the code daily, and so, I presume, do many others. So be
> careful...
>
>  Anyway, a lot of tests were made, hope they haven't been disabled (there was this one time...). If the tests
> pass the patch (or the other way ribs) and some more tests can be done that fail now and pass with the
> patch (thus demonstrating its usefulness), then I have nothing against said patch.

Unfortunately, the proposed change (btw, the diffs were backwards,
from new to old) fails some of the tests:

  Ran 901 tests, 889 results as expected, 12 unexpected (2025-10-11 11:38:16+0300, 5.800210 sec)

  12 unexpected results:
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-js-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-python-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-1-in-ruby-mode
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-3-in-python-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-3-in-ruby-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-4-in-js-mode-in-comments
     FAILED  electric-pair-inhibit-if-strings-mismatched-at-point-7-in-c-mode-in-comments
     FAILED  electric-pair-leave-unbalanced-quotes-alone-2-at-point-2-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-2-at-point-4-in-ruby-mode-in-comments
     FAILED  electric-pair-leave-unbalanced-quotes-alone-3-at-point-1-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-at-point-2-in-ruby-mode
     FAILED  electric-pair-leave-unbalanced-quotes-alone-at-point-4-in-ruby-mode-in-comments

So I don't think we can install this without some additional changes
to fix the regressions it causes.

It could also be the case that the test's expectation have been wrong or unrealistic for a long time. Please try "ert-describe-test" (or something like that) in one of those tests. The first one seems good enough. It should produce some sort of intelligible description of what the test is trying to assert. Then we can understand if it makes sense or not.

João

[Message part 2 (text/html, inline)]

Message #26 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dubois <at> valvesoftware.com, João Távora
 <joaotavora <at> gmail.com>
Cc: 79476 <at> debbugs.gnu.org
Subject: Re: bug#79476: 30.1; False negative in
 electric-pair-inhibit-if-helps-balance
Date: Sat, 25 Oct 2025 13:22:21 +0300

Ping!  Paul, could you please respond to João?

> From: João Távora <joaotavora <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  "79476 <at> debbugs.gnu.org"
>  <79476 <at> debbugs.gnu.org>
> Date: Sat, 11 Oct 2025 23:52:36 +0100
> 
> Paul Du Bois <dubois <at> valvesoftware.com> writes:
> 
> > Nice; if I'd like to look at and run the tests, where should I look
> > for instructions?
> 
> To run them non-interactively, more or less like the CI runs them, use
> `make` from the source tree of Emacs, after having built it (to build
> emacs there are plenty of instructions out there for doing that)
> 
>    make -C test electric-tests
> 
> I count about 901 today.  Most of these tests are for elec-pair.el which
> you edited.  You can filter just some of them with the SELECTOR env
> variable
> 
>   make -C test electric-tests SELECTOR='"quotes"'
> 
> paying close attention to the quoting, I'm using a combination of single
> and double quotes so that Emacs sees the Elisp string "quotes", and not
> the unbound symbol quotes.
> 
> It could be useful to you to you to run them interactively from within
> the Emacs session where you're hacking elec-pair.el.  To do that, find
> the file test/lisp/electric-tests.el, and load it with:
> 
>    M-x emacs-lisp-byte-compile-and-load
> 
> Then you may run tests with M-x ert.  This will read a selector from the
> minibuffer.  If you give it 't' it will run all the tests.
> 
> A word of caution.  I remember well that electric pair tests are highly
> sensitive to the syntax tables of modes and parse-partial-sexp.  This is
> how the code I wrote knows whether it is in a balanced or unbalanced
> situation to begin with.  So you may see different results depending on
> the complexity of your configuration, i.e. the amount of hacking you --
> or some package you're using -- applies on those syntax tables.  I
> recommend starting with a lean configuration (i.e. not very far from
> Emacs -Q) where all the tests pass interactively as well as
> non-interactively.
> 

Message #29 received at 79476 <at> debbugs.gnu.org (full text, mbox):

From: Paul Du Bois <dubois <at> valvesoftware.com>
To: 'Eli Zaretskii' <eliz <at> gnu.org>, João Távora
 <joaotavora <at> gmail.com>
Cc: "79476 <at> debbugs.gnu.org" <79476 <at> debbugs.gnu.org>
Subject: RE: [External Mail] Re: bug#79476: 30.1; False negative in
 electric-pair-inhibit-if-helps-balance
Date: Mon, 27 Oct 2025 22:45:56 +0000

Apologies, I didn't realize there was a direct question. I haven't gotten a working build from source on my personal computer yet, but when I do I'll try to get a better patch which doesn't fail tests (or retract the bug, if it seems impossible)

-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org> 

Ping!  Paul, could you please respond to João?

Previous Next

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