bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gustavo Barros
Subject: bug#36309: 26.2; Interaction between electric-pair and electric-quote
Date: Thu, 20 Jun 2019 10:20:00 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0


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 via email to

[Prev in Thread] Current Thread [Next in Thread]