bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Ergus]

In electric-pair-mode there are some files where inserting one " does
not insert the pair ". But on the other hand when I try to insert a
second " it inserts a pair for it so it ends with """.

It does not happen when the file is empty but for me it happens with
this file content.

---------------------------------------
#ifndef _SparseMatrix_functions_hpp_
#define _SparseMatrix_functions_hpp_



#endif
--------------------------------------- 

The behavior changes sometimes inserting a new line instead of the first
", or just not inserting any pair at all. This looks like an issue in a
backward search for a pair or something. Because it changes if withing
the define region or not.

When a region is active there is not issue and the quotes are inserted
in pairs around the region as expected.

This was reproduced with:

emacs -Q file.hpp
M-x electric-pair-modes

In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.9)
 of 2019-06-28 built on Ergus
Repository revision: cb182ce6f8d2fa6e1509252fecc2b0e504e36d63
Repository branch: master
System Description: Arch Linux



Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
main.hpp has auto save data; consider M-x recover-this-file
Electric-Pair mode enabled
funcall-interactively: End of buffer [3 times]
C-x <up> is undefined
user-error: End of history; no default available

Configured using:
 'configure --prefix=/home/ergo/PhD/emacs/emacs.install_arch
 --with-mailutils --with-x-toolkit=gtk3 --with-xft --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++//l

Minor modes in effect:
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-start cus-load
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs cl-loaddefs cl-lib term/tmux term/xterm xterm
elec-pair 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
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 77664 8509)
 (symbols 48 9388 1)
 (strings 32 23186 1893)
 (string-bytes 1 836866)
 (vectors 16 10470)
 (vector-slots 8 105810 5838)
 (floats 8 25 245)
 (intervals 56 215 0)
 (buffers 992 12))

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Alan Mackenzie]

Hello, Ergus.

On Fri, Jun 28, 2019 at 21:01:31 +0200, Ergus wrote:
> In electric-pair-mode there are some files where inserting one " does
> not insert the pair ". But on the other hand when I try to insert a
> second " it inserts a pair for it so it ends with """.

> It does not happen when the file is empty but for me it happens with
> this file content.

> ---------------------------------------
> #ifndef _SparseMatrix_functions_hpp_
> #define _SparseMatrix_functions_hpp_



> #endif
> --------------------------------------- 

I've just committed a fix to master which fixes some of the problem.
(For the rest of the problem, see bug #36474.)

> The behavior changes sometimes inserting a new line instead of the first
> ", or just not inserting any pair at all. This looks like an issue in a
> backward search for a pair or something. Because it changes if withing
> the define region or not.

Yes.

> When a region is active there is not issue and the quotes are inserted
> in pairs around the region as expected.

Also yes.

> This was reproduced with:

> emacs -Q file.hpp
> M-x electric-pair-modes

> In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.9)
>  of 2019-06-28 built on Ergus
> Repository revision: cb182ce6f8d2fa6e1509252fecc2b0e504e36d63
> Repository branch: master
> System Description: Arch Linux

Thanks for taking the trouble to report this.  It should be somewhat
better, now.  Just a small point: it would have been helpful if you'd
mentioned C++ Mode in the Subject: (or even explicitly in the message).

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

Hi Alan:

Sorry for the bother again. After the fix you did, the "" issue is
better, but now there are new issues with the {} when I use pragmas for
example.

I attached you a picture (because this is the easier way to explain it)

As you can see it does not recognize the pairs correctly in one
case. And in the other it does not recognize the () at all. (Maybe the
second is not exactly the same issue) 

The main problem is that because of this the automatic indentation is
affected.

An interesting thing is that in the line 136 out(vout[0; size]) it works
correctly. Maybe it has to do with the \ in the pragmas?

Thanks for the previous patch and in advance for the next ;)
Ergus


On Tue, Jul 02, 2019 at 01:36:41PM +0000, Alan Mackenzie wrote:
>Hello, Ergus.
>
>On Fri, Jun 28, 2019 at 21:01:31 +0200, Ergus wrote:
>> In electric-pair-mode there are some files where inserting one " does
>> not insert the pair ". But on the other hand when I try to insert a
>> second " it inserts a pair for it so it ends with """.
>
>> It does not happen when the file is empty but for me it happens with
>> this file content.
>
>> ---------------------------------------
>> #ifndef _SparseMatrix_functions_hpp_
>> #define _SparseMatrix_functions_hpp_
>
>
>
>> #endif
>> ---------------------------------------
>
>I've just committed a fix to master which fixes some of the problem.
>(For the rest of the problem, see bug #36474.)
>
>> The behavior changes sometimes inserting a new line instead of the first
>> ", or just not inserting any pair at all. This looks like an issue in a
>> backward search for a pair or something. Because it changes if withing
>> the define region or not.
>
>Yes.
>
>> When a region is active there is not issue and the quotes are inserted
>> in pairs around the region as expected.
>
>Also yes.
>
>> This was reproduced with:
>
>> emacs -Q file.hpp
>> M-x electric-pair-modes
>
>> In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.9)
>>  of 2019-06-28 built on Ergus
>> Repository revision: cb182ce6f8d2fa6e1509252fecc2b0e504e36d63
>> Repository branch: master
>> System Description: Arch Linux
>
>Thanks for taking the trouble to report this.  It should be somewhat
>better, now.  Just a small point: it would have been helpful if you'd
>mentioned C++ Mode in the Subject: (or even explicitly in the message).
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Screenshot_2019-07-03_21-14-59.png --]
[-- Type: image/png, Size: 25173 bytes --]

[-- Attachment #3: Screenshot_2019-07-03_21-22-52.png --]
[-- Type: image/png, Size: 20684 bytes --]

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Alan Mackenzie]

Hello, Ergus.

On Wed, Jul 03, 2019 at 21:32:00 +0200, Ergus wrote:
> Hi Alan:

> Sorry for the bother again.

No bother!

> After the fix you did, the "" issue is better, but now there are new
> issues with the {} when I use pragmas for example.

> I attached you a picture (because this is the easier way to explain it)

Nevertheless, is there any chance you could send me a copy of the code,
so that I don't have to type it in myself from the screenshots?

> As you can see it does not recognize the pairs correctly in one
> case. And in the other it does not recognize the () at all. (Maybe the
> second is not exactly the same issue) 

That, indeed, needs looking at.

> The main problem is that because of this the automatic indentation is
> affected.

> An interesting thing is that in the line 136 out(vout[0; size]) it works
> correctly. Maybe it has to do with the \ in the pragmas?

> Thanks for the previous patch and in advance for the next ;)
> Ergus

Let's look forward to that!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Alan Mackenzie]

Hello, Ergus.

On Wed, Jul 03, 2019 at 21:32:00 +0200, Ergus wrote:
> Hi Alan:

> Sorry for the bother again. After the fix you did, the "" issue is
> better, but now there are new issues with the {} when I use pragmas for
> example.

OK, thanks!  I've corrected a further problem with " in
electric-pair-mode, and I'm taking the liberty of closing your bug.  ;-)

> I attached you a picture (because this is the easier way to explain it)

This is actually a different bug.  If you haven't done so already, could
you please raise this as a bug in its own right.  Thanks.

Just as a matter of interest, please enclose a copy of the C++ file (or
even better, just the relevant part of it) so as to save me the bother of
having to type it in.  Thanks!

> As you can see it does not recognize the pairs correctly in one
> case. And in the other it does not recognize the () at all. (Maybe the
> second is not exactly the same issue) 

> The main problem is that because of this the automatic indentation is
> affected.

> An interesting thing is that in the line 136 out(vout[0; size]) it works
> correctly. Maybe it has to do with the \ in the pragmas?

> Thanks for the previous patch and in advance for the next ;)
> Ergus

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36423: 27.0.50; electric-pair-mode not working properly depending of file content.

[Alan Mackenzie]

Hello again, Ergus.

On Mon, Jul 08, 2019 at 09:48:01 +0000, Alan Mackenzie wrote:
> On Wed, Jul 03, 2019 at 21:32:00 +0200, Ergus wrote:
> > Hi Alan:

> > Sorry for the bother again. After the fix you did, the "" issue is
> > better, but now there are new issues with the {} when I use pragmas for
> > example.

> OK, thanks!  I've corrected a further problem with " in
> electric-pair-mode, and I'm taking the liberty of closing your bug.  ;-)

> > I attached you a picture (because this is the easier way to explain it)

> This is actually a different bug.  If you haven't done so already, could
> you please raise this as a bug in its own right.  Thanks.

Actually, there's no need for this, I understand what's happening now
and it's "not a bug" - sort of.

In the lines:

1.    printf ("Hello
2.             world");

, there is an invalid string on L1, extending from " to the end of the
line.  There is also an invalid string on L2, starting at the ", which
encloses the ).  Thus this ), being inside a string, can't match the (
on L1.

Sorry I hadn't realised this half an hour ago.

Due to insistent complaints, I'm looking at modifying this "invalid
string" mechanism so that although it would fontify as it does now, it
would allow things like these two parentheses to match up.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).