GNU bug report logs - #36307
26.2; Interaction between electric-pair and electric-quote

Previous Next

Package: emacs;

Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>

Date: Thu, 20 Jun 2019 13:21:02 UTC

Severity: minor

Merged with 36309

Found in version 26.2

Full log


View this message in rfc822 format

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: 36307 <at> debbugs.gnu.org
Cc: João Távora <joaotavora <at> gmail.com>
Subject: bug#36307: 26.2; Interaction between electric-pair and electric-quote
Date: Mon, 19 Apr 2021 12:53:28 -0300
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.





This bug report was last modified 3 years and 244 days ago.

Previous Next


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