* bug#36307: 26.2; Interaction between electric-pair and electric-quote @ 2019-06-20 13:20 Gustavo Barros 2019-06-26 17:37 ` Gustavo Barros 0 siblings, 1 reply; 8+ messages in thread From: Gustavo Barros @ 2019-06-20 13:20 UTC (permalink / raw) To: 36307 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)) ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2019-06-20 13:20 bug#36307: 26.2; Interaction between electric-pair and electric-quote Gustavo Barros @ 2019-06-26 17:37 ` Gustavo Barros 2019-09-18 20:26 ` Gustavo Barros 0 siblings, 1 reply; 8+ messages in thread From: Gustavo Barros @ 2019-06-26 17:37 UTC (permalink / raw) To: 36307 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)) ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2019-06-26 17:37 ` Gustavo Barros @ 2019-09-18 20:26 ` Gustavo Barros 2021-04-19 15:53 ` Gustavo Barros 0 siblings, 1 reply; 8+ messages in thread From: Gustavo Barros @ 2019-09-18 20:26 UTC (permalink / raw) To: 36307 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2019-09-18 20:26 ` Gustavo Barros @ 2021-04-19 15:53 ` Gustavo Barros 2021-04-19 19:12 ` João Távora 0 siblings, 1 reply; 8+ messages in thread From: Gustavo Barros @ 2021-04-19 15:53 UTC (permalink / raw) To: 36307; +Cc: João Távora 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2021-04-19 15:53 ` Gustavo Barros @ 2021-04-19 19:12 ` João Távora 2021-04-19 19:16 ` João Távora 2021-10-19 9:35 ` Gustavo Barros 0 siblings, 2 replies; 8+ messages in thread From: João Távora @ 2021-04-19 19:12 UTC (permalink / raw) To: Gustavo Barros; +Cc: 36307 [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2021-04-19 19:12 ` João Távora @ 2021-04-19 19:16 ` João Távora 2021-04-19 19:55 ` Gustavo Barros 2021-10-19 9:35 ` Gustavo Barros 1 sibling, 1 reply; 8+ messages in thread From: João Távora @ 2021-04-19 19:16 UTC (permalink / raw) To: Gustavo Barros; +Cc: 36307 [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2021-04-19 19:16 ` João Távora @ 2021-04-19 19:55 ` Gustavo Barros 0 siblings, 0 replies; 8+ messages in thread From: Gustavo Barros @ 2021-04-19 19:55 UTC (permalink / raw) To: João Távora; +Cc: 36307 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#36307: 26.2; Interaction between electric-pair and electric-quote 2021-04-19 19:12 ` João Távora 2021-04-19 19:16 ` João Távora @ 2021-10-19 9:35 ` Gustavo Barros 1 sibling, 0 replies; 8+ messages in thread From: Gustavo Barros @ 2021-10-19 9:35 UTC (permalink / raw) To: João Távora; +Cc: 36307 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-19 9:35 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-06-20 13:20 bug#36307: 26.2; Interaction between electric-pair and electric-quote Gustavo Barros 2019-06-26 17:37 ` Gustavo Barros 2019-09-18 20:26 ` Gustavo Barros 2021-04-19 15:53 ` Gustavo Barros 2021-04-19 19:12 ` João Távora 2021-04-19 19:16 ` João Távora 2021-04-19 19:55 ` Gustavo Barros 2021-10-19 9:35 ` Gustavo Barros
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.