From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Gustavo Barros Newsgroups: gmane.emacs.bugs Subject: bug#36307: 26.2; Interaction between electric-pair and electric-quote Date: Wed, 26 Jun 2019 14:37:01 -0300 Message-ID: <874l4cdz9e.fsf@gmail.com> References: <2dbd590d-acce-8ab8-124a-5e5fe811c578@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="229396"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.2.0; emacs 26.2 To: 36307@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 26 19:38:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgBs4-000xTu-2Y for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Jun 2019 19:38:12 +0200 Original-Received: from localhost ([::1]:43886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgBs2-0002sY-Nx for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Jun 2019 13:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59102) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgBrw-0002sJ-67 for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 13:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgBru-0008By-4y for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 13:38:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51694) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgBrt-0008Bd-TW for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 13:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgBrt-00040G-K7 for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 13:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustavo Barros Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Jun 2019 17:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36307 X-GNU-PR-Package: emacs Original-Received: via spool by 36307-submit@debbugs.gnu.org id=B36307.156157063615330 (code B ref 36307); Wed, 26 Jun 2019 17:38:01 +0000 Original-Received: (at 36307) by debbugs.gnu.org; 26 Jun 2019 17:37:16 +0000 Original-Received: from localhost ([127.0.0.1]:37005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgBrA-0003zB-6q for submit@debbugs.gnu.org; Wed, 26 Jun 2019 13:37:16 -0400 Original-Received: from mail-qt1-f181.google.com ([209.85.160.181]:46226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgBr7-0003yt-Hx for 36307@debbugs.gnu.org; Wed, 26 Jun 2019 13:37:14 -0400 Original-Received: by mail-qt1-f181.google.com with SMTP id h21so3245328qtn.13 for <36307@debbugs.gnu.org>; Wed, 26 Jun 2019 10:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:references:user-agent:from:to:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=elO90dp6uhz9M9d13aKMP0uMhOwQOU5HXtlzqwZY6P8=; b=pJebPQ0NQ+VFmHgvFw7EVqwnpujG9rc76kWlnCjHUHRCKib4NdXspfGFrlQHryqVrU k2UJmZQrxjtheCSzs4182JBnxL1ypJ0te5hBCHJ7yPUB617irsV3Jizsh/p+EXlZeVC8 MJ+zrhYmJckzsUvzDio1mgIoULeU9rs1kRsW4mLCRWTogpqPeLWsAermKzT8I8wjgmny 6TFjGMwjkFWn4K+DKvn2RubHuZ3K9WjclsOgo1HDihK0dpheFSBpQ+mcoTDwTaY5q7KM lDRYsIFf6+m8MKvyMT6I8q40FCcg8zqRHQ7kNrpzNiCN3DtOABK32yne1TpYQrGiTI1x xdFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:references:user-agent:from:to:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=elO90dp6uhz9M9d13aKMP0uMhOwQOU5HXtlzqwZY6P8=; b=GQW/tinIvbstEk8GjFpSNKNauq7pwZERYg3jThj7PIITIUaNjTwqRaabUoHq/OuK1L 6qBoK7gxJNqgF9ntlDeWa0x3ShRawfN8SaWYebfSrTmp1PBDGIjwHBbeaIhF5Xl4PItU vdasvANNfKbh6325E7NhJ5++j6bJ/W8ofDcJSBb0O2HvDvKLx60MMBduTCFXUx8vIhjc RzRgng5ezN1KhfYMx5zWlXCGJrS1n3fXiwF5LUIm8A5BdpKBFK1fht45dXVXAerouScw zNE10p/w5F+CM5nqFfYO0n6D2++lpG0DZzJE3QA71GhzQiLhFhpdyuiH/4mnvUoSSpZ7 A+5g== X-Gm-Message-State: APjAAAVN/m5/uGwdy4u+kiztFA1OsDVUfh7/iSEU20Ez5fTKx7SowZ0N 76WXCAuY/yOr7yAZfrU8tK8uisRXEN8= X-Google-Smtp-Source: APXvYqwXhSxwh/BMSFrIc4cVFmghlpf+2L2xN8yuXMXxYhaYvufASWKjs+tG2/JOnGctjD4ht0/JrQ== X-Received: by 2002:ac8:21b7:: with SMTP id 52mr4758521qty.59.1561570626644; Wed, 26 Jun 2019 10:37:06 -0700 (PDT) Original-Received: from ufjf-desktop (ip200131561.nat10.ufjf.br. [200.131.56.1]) by smtp.gmail.com with ESMTPSA id x205sm8782273qka.56.2019.06.26.10.37.04 for <36307@debbugs.gnu.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Jun 2019 10:37:05 -0700 (PDT) In-reply-to: <2dbd590d-acce-8ab8-124a-5e5fe811c578@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161536 Archived-At: 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 wro= te.=20 The first is =3Delectric-quote-context-sensitive=3D, which I don't know how= I had=20 missed. This means the suggestion I made to have a context sensitive elect= ric=20 quote is already in place. The second thing I had missed is how convenient the typing strategy=20 implemented by electric quote can be, in the appropriate (or more common)=20 setting. The reason I had failed to see this is that I use a pt_br keyboar= d=20 where the backtick key is both a shift key and an accent key, that is, I ha= d=20 to press it four times holding shift to get a double quote. Having found o= ut=20 about =3Delectric-quote-context-sensitive=3D, though, allows me to use the = single=20 quote, which is neither a shift nor an accent key in my keyboard, and I mus= t=20 recognize it is indeed neat. Better than the chord the shift key would=20 require. So, this is true for all who use an US international keyboard, in= =20 which both the single quote and the backtick are of convenient typing. Thi= s=20 is general enough, but might not be universal. All in all, I take back my final suggestion. What is already in place is=20 superior to what I had envisaged and suggested. However, the cases described in the report could indeed work for electric=20 quotes in a more akin fashion to other electric pairs. If this is possible= , I=20 think it is still desirable. In this respect, I've reached a temporary workaround to inhibit the pairing= in=20 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~=20 clause, and had initially tried to use the same inhibit criteria as I use f= or=20 the remaining electric pairs, that is simply using=20 ~electric-pair-inhibit-predicate~. This led to some undesired behavior at = the=20 moment of *closing* the quotes, which did not skip as expected. So, as far= as=20 I can tell, different pairing inhibit rules might be needed for electric=20 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 s= ome > 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=20 > I > try to document some specific ones I've identified more precisely. > > So, in the examples bellow, I'll consider mostly two cases: quote inserti= on=20 > on > a left word boundary, and quote insertion on an active region. In them, I= =20 > 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 =E2=80=98=E2=80=99bar baz > foo =E2=80=98bar=E2=80=99 baz > #+end_example > > But the expected result would be: > > #+begin_example > foo =E2=80=98bar baz > foo =E2=80=98bar=E2=80=99 baz > #+end_example > > Well, this is 'expected' as far as I can see. Its worth noting though tha= t=20 > 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=20 > braces, > parentheses etc. So I don't really know if I'm missing something, and thi= s=20 > is > expected behavior of the selected 'electric-pair-inhibit-predicate' in te= xt > mode, or if there is something else in play. > > Now, if we type `` (two backticks), we get: > > #+begin_example > foo =E2=80=9C=E2=80=9Dbar baz > foo =E2=80=9C=E2=80=9Dbar=E2=80=99 baz > #+end_example > > But the expected result would be: > > #+begin_example > foo =E2=80=9Cbar baz > foo =E2=80=9Cbar=E2=80=9D 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 =E2=80=98=E2=80=99bar baz > foo =E2=80=98=E2=80=99 baz > #+end_example > > And, if we type `` (two backticks), we get: > > #+begin_example > foo =E2=80=9C=E2=80=9Dbar baz > foo =E2=80=9C=E2=80=9D 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= =20 > not > to be expected. But, beyond that, I'd like to add a related suggestion,=20 > 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 ge= t=20 > 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=20 > typing > of either key complicates their pairing in the active region case. For, a= s=20 > is > expected, after the first (single) quote is inserted, the region is no=20 > longer > active. There might be ways around this, I don't know. > > Still, making 'electric-quote-mode' (more) context-sensitive may relieve = it=20 > 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 a= lso > 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 se= em > natural candidates), this would likely streamline curved quotes to behave= in > similar fashion as their other electric-pair relatives. In my view, it wo= uld > 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))