bug#36307: 26.2; Interaction between electric-pair and electric-quote

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

I've been using both 'electric-pair-mode' and 'electric-quote-mode' for 
some
time, and they mostly come in really handy. So they are appreciated. But
their interaction still leaves some things to be desired for: in sum,
electric-quotes do not behave as other electric-pairs. Thus this report.

I don't think I can exhaust all the cases involved in their interaction, 
but I
try to document some specific ones I've identified more precisely.

So, in the examples bellow, I'll consider mostly two cases: quote 
insertion on
a left word boundary, and quote insertion on an active region. In them, 
I use
"|" to denote point position and "|foo|" to denote an active region.

Steps followed:

#+begin_src bash
emacs -Q
#+end_src

Then:

#+begin_src emacs-lisp
(text-mode)
(electric-pair-mode)
(electric-quote-mode)
(setq electric-pair-inhibit-predicate 'electric-pair-conservative-inhibit)
#+end_src

With this settings in hand, and in the following situations (as described
above):

#+begin_example
foo |bar baz
foo |bar| baz
#+end_example

If we type ` (one backtick), the result is:

#+begin_example
foo ‘’bar baz
foo ‘bar’ baz
#+end_example

But the expected result would be:

#+begin_example
foo ‘bar baz
foo ‘bar’ baz
#+end_example

Well, this is 'expected' as far as I can see. Its worth noting though 
that it
is the same behavior exhibited by inserting " (a double quote), thus
independently of electric-quote. That is, the pair is inserted in the left
boundary of 'bar' for a double quote. This happens in text-mode, but not in
emacs-lisp-mode, code or comments, or in org-mode. The pairing in this
position also does not happen for other electric-pair symbols, such as 
braces,
parentheses etc. So I don't really know if I'm missing something, and 
this is
expected behavior of the selected 'electric-pair-inhibit-predicate' in text
mode, or if there is something else in play.

Now, if we type `` (two backticks), we get:

#+begin_example
foo “”bar baz
foo “”bar’ baz
#+end_example

But the expected result would be:

#+begin_example
foo “bar baz
foo “bar” baz
#+end_example

Yet, if we further add 'delete-selection' to the bunch:

#+begin_src emacs-lisp
(delete-selection-mode)
#+end_src

If we type ` (one backtick), the result is:

#+begin_example
foo ‘’bar baz
foo ‘’ baz
#+end_example

And, if we type `` (two backticks), we get:

#+begin_example
foo “”bar baz
foo “” baz
#+end_example

The expectation here is that results should not be affected by
'delete-selection-mode'. As is the case for other electric-pair pairs.


Well, this is the report describing the relevant behavior, that I 
believe not
to be expected. But, beyond that, I'd like to add a related suggestion, 
which
I think is pertinent to the issue at hand.

The typing strategy adopted by 'electric-quote-mode' relies on the 
typing of
two keys (' single quote; ` backtick), which have to be typed twice to 
get to
a double curved quote. (True, electric-pair can reduce this typing, but
that's independent.)

Now, the fact that double curved quotes are inserted by the sequential 
typing
of either key complicates their pairing in the active region case. For, 
as is
expected, after the first (single) quote is inserted, the region is no 
longer
active. There might be ways around this, I don't know.

Still, making 'electric-quote-mode' (more) context-sensitive may relieve 
it of
the sequencial key pressing, and help solve this technical difficulty.
E.g. on a left word boundary, insert a left curved quote; on a right word
boundary, insert a right curved quote, and so on. Of course, the relevant
cases would have to be thought through. And, of course, a way to force
desired behavior in case context-sensitivity doesn't get it right would 
also
have to be provided.

But, in this fashion, 'electric-quote-mode' could rely on a single
key-pressing for each kind of quote (' single quote and " double quote seem
natural candidates), this would likely streamline curved quotes to 
behave in
similar fashion as their other electric-pair relatives. In my view, it 
would
also improve editing experience.


Best regards,
Gustavo Barros.









In GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-04-19 built on gusbrs-laptop
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19.1 Tessa

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [2 times]
nil
t [2 times]
electric-pair-conservative-inhibit
t

Configured using:
'configure --with-mailutils --with-xwidgets --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD LCMS2

Important settings:
value of $LC_MONETARY: pt_BR.UTF-8
value of $LC_NUMERIC: pt_BR.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
delete-selection-mode: t
electric-pair-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-quote-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
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils delsel elec-pair
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic 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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 95028 8687)
(symbols 48 20427 2)
(miscs 40 57 129)
(strings 32 28461 1206)
(string-bytes 1 748945)
(vectors 16 14089)
(vector-slots 8 502824 10466)
(floats 8 51 322)
(intervals 56 225 0)
(buffers 992 11))

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

I've been looking further into this, and have some things to add.

I had missed two things in the current available structure when I first wrote. 
The first is =electric-quote-context-sensitive=, which I don't know how I had 
missed.  This means the suggestion I made to have a context sensitive electric 
quote is already in place.

The second thing I had missed is how convenient the typing strategy 
implemented by electric quote can be, in the appropriate (or more common) 
setting.  The reason I had failed to see this is that I use a pt_br keyboard 
where the backtick key is both a shift key and an accent key, that is, I had 
to press it four times holding shift to get a double quote.  Having found out 
about =electric-quote-context-sensitive=, though, allows me to use the single 
quote, which is neither a shift nor an accent key in my keyboard, and I must 
recognize it is indeed neat.  Better than the chord the shift key would 
require.  So, this is true for all who use an US international keyboard, in 
which both the single quote and the backtick are of convenient typing.  This 
is general enough, but might not be universal.

All in all, I take back my final suggestion.  What is already in place is 
superior to what I had envisaged and suggested.

However, the cases described in the report could indeed work for electric 
quotes in a more akin fashion to other electric pairs.  If this is possible, I 
think it is still desirable.

In this respect, I've reached a temporary workaround to inhibit the pairing in 
a left word boundary (no bliss yet for del-sel though):

#+begin_src emacs-lisp
(defun my/electric-quote-inhibit-pair (orig-fun &rest args)
  (apply orig-fun args)
  (when (eq (char-syntax (following-char)) ?w); only before words.
    (pcase electric-quote-chars
      (`(,q< ,q> ,q<< ,q>>)
       (save-excursion
         (cond ((search-backward (string q>) (1- (point)) t)
                (replace-match ""))
               ((search-backward (string q>>) (1- (point)) t)
                (replace-match ""))))))))
(advice-add 'electric-quote-post-self-insert-function
            :around #'my/electric-quote-inhibit-pair)
#+end_src

I bring this because I played with different inhibit rules in the ~when~ 
clause, and had initially tried to use the same inhibit criteria as I use for 
the remaining electric pairs, that is simply using 
~electric-pair-inhibit-predicate~.  This led to some undesired behavior at the 
moment of *closing* the quotes, which did not skip as expected.  So, as far as 
I can tell, different pairing inhibit rules might be needed for electric 
quotes in particular.  For this workaround I kept only left word boundaries.


Best regards,
Gustavo Barros.


On Thu, Jun 20 2019, Gustavo Barros wrote:

> I've been using both 'electric-pair-mode' and 'electric-quote-mode' for some
> time, and they mostly come in really handy. So they are appreciated. But
> their interaction still leaves some things to be desired for: in sum,
> electric-quotes do not behave as other electric-pairs. Thus this report.
>
> I don't think I can exhaust all the cases involved in their interaction, but 
> I
> try to document some specific ones I've identified more precisely.
>
> So, in the examples bellow, I'll consider mostly two cases: quote insertion 
> on
> a left word boundary, and quote insertion on an active region. In them, I 
> use
> "|" to denote point position and "|foo|" to denote an active region.
>
> Steps followed:
>
> #+begin_src bash
> emacs -Q
> #+end_src
>
> Then:
>
> #+begin_src emacs-lisp
> (text-mode)
> (electric-pair-mode)
> (electric-quote-mode)
> (setq electric-pair-inhibit-predicate 'electric-pair-conservative-inhibit)
> #+end_src
>
> With this settings in hand, and in the following situations (as described
> above):
>
> #+begin_example
> foo |bar baz
> foo |bar| baz
> #+end_example
>
> If we type ` (one backtick), the result is:
>
> #+begin_example
> foo ‘’bar baz
> foo ‘bar’ baz
> #+end_example
>
> But the expected result would be:
>
> #+begin_example
> foo ‘bar baz
> foo ‘bar’ baz
> #+end_example
>
> Well, this is 'expected' as far as I can see. Its worth noting though that 
> it
> is the same behavior exhibited by inserting " (a double quote), thus
> independently of electric-quote. That is, the pair is inserted in the left
> boundary of 'bar' for a double quote. This happens in text-mode, but not in
> emacs-lisp-mode, code or comments, or in org-mode. The pairing in this
> position also does not happen for other electric-pair symbols, such as 
> braces,
> parentheses etc. So I don't really know if I'm missing something, and this 
> is
> expected behavior of the selected 'electric-pair-inhibit-predicate' in text
> mode, or if there is something else in play.
>
> Now, if we type `` (two backticks), we get:
>
> #+begin_example
> foo “”bar baz
> foo “”bar’ baz
> #+end_example
>
> But the expected result would be:
>
> #+begin_example
> foo “bar baz
> foo “bar” baz
> #+end_example
>
> Yet, if we further add 'delete-selection' to the bunch:
>
> #+begin_src emacs-lisp
> (delete-selection-mode)
> #+end_src
>
> If we type ` (one backtick), the result is:
>
> #+begin_example
> foo ‘’bar baz
> foo ‘’ baz
> #+end_example
>
> And, if we type `` (two backticks), we get:
>
> #+begin_example
> foo “”bar baz
> foo “” baz
> #+end_example
>
> The expectation here is that results should not be affected by
> 'delete-selection-mode'. As is the case for other electric-pair pairs.
>
>
> Well, this is the report describing the relevant behavior, that I believe 
> not
> to be expected. But, beyond that, I'd like to add a related suggestion, 
> which
> I think is pertinent to the issue at hand.
>
> The typing strategy adopted by 'electric-quote-mode' relies on the typing of
> two keys (' single quote; ` backtick), which have to be typed twice to get 
> to
> a double curved quote. (True, electric-pair can reduce this typing, but
> that's independent.)
>
> Now, the fact that double curved quotes are inserted by the sequential 
> typing
> of either key complicates their pairing in the active region case. For, as 
> is
> expected, after the first (single) quote is inserted, the region is no 
> longer
> active. There might be ways around this, I don't know.
>
> Still, making 'electric-quote-mode' (more) context-sensitive may relieve it 
> of
> the sequencial key pressing, and help solve this technical difficulty.
> E.g. on a left word boundary, insert a left curved quote; on a right word
> boundary, insert a right curved quote, and so on. Of course, the relevant
> cases would have to be thought through. And, of course, a way to force
> desired behavior in case context-sensitivity doesn't get it right would also
> have to be provided.
>
> But, in this fashion, 'electric-quote-mode' could rely on a single
> key-pressing for each kind of quote (' single quote and " double quote seem
> natural candidates), this would likely streamline curved quotes to behave in
> similar fashion as their other electric-pair relatives. In my view, it would
> also improve editing experience.
>
>
> Best regards,
> Gustavo Barros.
>
>
>
>
>
>
>
>
>
> In GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
> of 2019-04-19 built on gusbrs-laptop
> Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
> System Description: Linux Mint 19.1 Tessa
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Mark set [2 times]
> nil
> t [2 times]
> electric-pair-conservative-inhibit
> t
>
> Configured using:
> 'configure --with-mailutils --with-xwidgets --with-modules'
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
> NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
> LIBSYSTEMD LCMS2
>
> Important settings:
> value of $LC_MONETARY: pt_BR.UTF-8
> value of $LC_NUMERIC: pt_BR.UTF-8
> value of $LANG: en_US.UTF-8
> locale-coding-system: utf-8-unix
>
> Major mode: Text
>
> Minor modes in effect:
> delete-selection-mode: t
> electric-pair-mode: t
> tooltip-mode: t
> global-eldoc-mode: t
> electric-quote-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
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
> bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
> format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
> epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
> mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
> rfc2045 ietf-drums mm-util mail-prsvr mail-utils delsel elec-pair
> time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
> dnd fontset image regexp-opt fringe tabulated-list replace newcomment
> text-mode elisp-mode lisp-mode prog-mode register page menu-bar
> rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
> syntax facemenu font-core term/tty-colors frame cl-generic 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 charscript charprop
> case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
> cl-preloaded nadvice loaddefs button faces cus-face macroexp files
> text-properties overlay sha1 md5 base64 format env code-pages mule
> custom widget hashtable-print-readable backquote threads dbusbind
> inotify lcms2 dynamic-setting system-font-setting font-render-setting
> xwidget-internal move-toolbar gtk x-toolkit x multi-tty
> make-network-process emacs)
>
> Memory information:
> ((conses 16 95028 8687)
> (symbols 48 20427 2)
> (miscs 40 57 129)
> (strings 32 28461 1206)
> (string-bytes 1 748945)
> (vectors 16 14089)
> (vector-slots 8 502824 10466)
> (floats 8 51 322)
> (intervals 56 225 0)
> (buffers 992 11))

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

Hi all,

On Wed, Jun 26 2019, Gustavo Barros wrote:

> In this respect, I've reached a temporary workaround to inhibit the 
> pairing in
> a left word boundary (no bliss yet for del-sel though):
>
> #+begin_src emacs-lisp
> (defun my/electric-quote-inhibit-pair (orig-fun &rest args)
>  (apply orig-fun args)
>  (when (eq (char-syntax (following-char)) ?w); only before words.
>    (pcase electric-quote-chars
>      (`(,q< ,q> ,q<< ,q>>)
>       (save-excursion
>         (cond ((search-backward (string q>) (1- (point)) t)
>                (replace-match ""))
>               ((search-backward (string q>>) (1- (point)) t)
>                (replace-match ""))))))))
> (advice-add 'electric-quote-post-self-insert-function
>            :around #'my/electric-quote-inhibit-pair)
> #+end_src
>

In case this might be useful to anyone, I’ve improved this somewhat to 
handle better the case where point is mid-word:

#+begin_src emacs-lisp
(defun my/electric-quote-inhibit-pair (orig-fun &rest args)
  (if (and
       (not (eq (char-syntax (preceding-char)) ?w)); no word char before 
       point
       (eq (char-syntax (following-char)) ?w)); word char after point
      ;; If at the beginning of a word
      (progn
        (apply orig-fun args)
        (pcase electric-quote-chars
          (`(,q< ,q> ,q<< ,q>>)
           (save-excursion
             (cond ((search-backward (string q>) (1- (point)) t)
                    (replace-match ""))
                   ((search-backward (string q>>) (1- (point)) t)
                    (replace-match "")))))))
    ;; Else do as usual
    (apply orig-fun args)))

(advice-add 'electric-quote-post-self-insert-function
            :around #'my/electric-quote-inhibit-pair)
#+end_src


Best regards,
Gustavo.

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

Hi All,

This is an old report which, admittedly, was originally somewhat 
confusing (not my best job at that).  But I came back to this issue 
recently and I think I got a better grasp of what's going on, and can 
thus provide a clear diagnostic of where the problem lies.

There's an interaction between `electric-quote-mode' and 
`electric-pair-mode' such that `electric-pair-inhibit-predicate' is 
ignored for electric quotes.  What I failed to get when I originally 
reported is that, given the depths set at each of these modes' hooks, 
`electric-indent-post-self-insert-function' runs before 
`electric-pair-post-self-insert-function'.  This is why all of my 
attempts to tamper with the former (some of which I shared in this 
thread) had one or another shortcoming.  This is also the reason why 
`electric-pair-inhibit-predicate' is ignored by the later, since when 
`electric-pair-post-self-insert-function' runs, the electric quote 
substitution has already taken place.  However, the call to 
`electric-pair-inhibit-predicate' is behind a check on the syntax class 
of character being paired (or not) (the check is `(memq syntax '(?\( ?\" 
?\$))').  The curved quotes, depending on the syntax table of the 
major-mode, but usually, will fail this test, thus the pair will be 
inserted regardless of `electric-pair-inhibit-predicate'.  As far as I 
get, the same is true for `electric-pair-skip-whitespace-function', but 
I cannot generate a case where this is problematic (perhaps this is 
handled on `electric-quote-mode's side, I'm not sure).

A simple test to check that this is the case is the following.  Starting 
from `emacs -Q' (I'm running 27.2):

#+begin_src emacs-lisp
(defun my-electric-pair-inhibit-all ()
  t)

(setq electric-pair-inhibit-predicate 'my-electric-pair-inhibit-all)

(setq electric-quote-context-sensitive t)
(setq electric-quote-replace-double t)

(electric-pair-mode 1)
#+end_src

Now, this has thus far enabled `electric-pair-mode' but in a way that 
all and any pairing is (or should be) inhibited by 
`my-electric-pair-inhibit-all'.  Play with common pairs, particularly 
with the quotes, and see that this is actually the case: pairing does 
not take place.  Well, this is not true always, it is true for 
`lisp-interaction-mode', and for `org-mode'.  It is not true for 
`text-mode', and I presume that for the same reason that the pairing of 
curved quotes fail to get inhibited elsewhere: the syntax class of the 
character in question.

Now enable `electric-quote-mode', and play again with common pairs, 
particularly with quotes.  I've tested on `lisp-interaction-mode', 
`org-mode' and `text-mode'.  Of course, in the case of the first, and 
all those derived from `prog-mode', electric quoting is only done (by 
default) in comments and strings, but whenever the (opening) curved 
quote kicks in, their (closing) pair comes along.  Which demonstrates 
that `electric-pair-inhibit-predicate' is being ignored.

I don't know what is the best fix for this, but I hope this clearer 
diagnostic of the problem is of some use.  Since this is a long standing 
issue/report, and since I think this report circumscribes the issue much 
better than the original, I took the liberty of CC'ing João, as the 
maintainer of `elec-pair.el', I hope that is not inappropriate.

Best regards,
Gustavo.

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[João Távora]

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

> better than the original, I took the liberty of CC'ing João, as the
> maintainer of `elec-pair.el', I hope that is not inappropriate.

It's certainly not.  It's a very good idea even, at least in my case.

But it's going to take me a while to process this, so make sure to ping
me in the future if I don't manage to.

João

[-- Attachment #2: Type: text/html, Size: 503 bytes --]

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[João Távora]

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

After reading your issue in diagonal, it seems it's to do with
electric-quote-mode and electric-pair-mode.  I wrote the latter
mostly, but I didn't write the former, which I think is only for
UTF-8 quotes.  I personally turn it off.  I don't think it respects
the auto-balancing ideas I put into electric-pair-mode.

(if that's even what you're asking about, I still haven't read and
processed all your text).

João

[-- Attachment #2: Type: text/html, Size: 616 bytes --]

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

Hi João,

On Mon, 19 Apr 2021 at 16:16, João Távora <joaotavora@gmail.com> wrote:

> After reading your issue in diagonal, it seems it's to do with
> electric-quote-mode and electric-pair-mode.  I wrote the latter
> mostly, but I didn't write the former, which I think is only for
> UTF-8 quotes.  I personally turn it off.  I don't think it respects
> the auto-balancing ideas I put into electric-pair-mode.
>
> (if that's even what you're asking about, I still haven't read and
> processed all your text).
>

Thanks for answering.

Yes, the TL;DR is: `electric-pair-mode' ignores 
`electric-pair-inhibit-predicate' and 
`electric-pair-skip-whitespace-function' when the input character is not 
of syntax class `(?\( ?\" ?\$)'.

This indeed affects `electric-quote-mode', thought the problem is in 
`electric-pair-mode' and should be dealt with there since the check 
happens in `electric-pair-post-self-insert-function' which runs after 
`electric-quote-mode's post-self-insert-function.  As a matter of fact, 
the reproduction example in the full report shows a case where 
`electric-pair-mode' fails for this reason by itself, without 
`electric-quote-mode'.  The case is `text-mode' where "\"" is of syntax 
class punctuation (not string), so that the pairing is never inhibited.

And I'm fine with whatever is your timing for this.  I had been living 
with half measures for a couple of years now, and now that I understood 
the problem better I could come up with a better local workaround (no 
good for a proper fix, unfortunately).  I really just reported back 
because it would be nice if this was fixed upstream.

Best regards,
Gustavo.

PS: I wrote in the report:

> What I failed to get when I originally reported is that, given the 
> depths set at each of these modes' hooks, 
> `electric-indent-post-self-insert-function' runs before 
> `electric-pair-post-self-insert-function'.

And I meant "`electric-quote-post-self-insert-function' runs before 
`electric-pair-post-self-insert-function'".  It was a copy-paste 
mistake, `electric-indent-mode' is out of the picture here altogether.

bug#36307: 26.2; Interaction between electric-pair and electric-quote

[Gustavo Barros]

Hi João,

On Mon, 19 Apr 2021 at 20:12, João Távora <joaotavora@gmail.com> wrote:
>
> It's certainly not.  It's a very good idea even, at least in my case.
>
> But it's going to take me a while to process this, so make sure to 
> ping 
> me in the future if I don't manage to.
>
> João

You had asked for a ping in this thread and I thought it's already 
fairly behind us for a respectful bump on this thread.

If you (or someone) could take a look at this, it'd still be much 
appreciated.

Best regards,
Gustavo.