all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: 36307@debbugs.gnu.org
Subject: bug#36307: 26.2; Interaction between electric-pair and electric-quote
Date: Wed, 26 Jun 2019 14:37:01 -0300	[thread overview]
Message-ID: <874l4cdz9e.fsf@gmail.com> (raw)
In-Reply-To: <2dbd590d-acce-8ab8-124a-5e5fe811c578@gmail.com>


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))






  reply	other threads:[~2019-06-26 17:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874l4cdz9e.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=36307@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.