Re: CC Mode and electric-pair "problem".

[Alan Mackenzie <acm@muc.de>]

Hello, João

On Thu, May 31, 2018 at 17:07:43 +0100, João Távora wrote:
> Hi again, Alan

> Alan Mackenzie <acm@muc.de> writes:

> >     " (
> >
> >       ) "
> >
> > .  With point just after the (, type a ).  The expected result is that
> > everything up to and including the existing ) gets "chomped", leaving
> > the buffer looking like:
> >
> >     " () "
> >
> > .  This no longer happens in C++ mode, and it is not clear that it
> > should.  In the original buffer, ( and ) are not in the same string,
> > since the opening string ends at EOL, there being no backslash to
> > continue it.
> >
> > If there were escaped newlines in the buffer, I don't think the "chomp"
> > would work, because elec-pair.el doesn't recognise escaped newlines as
> > whitespace.
> >
> > Comments?

> I can reproduce this, even without turning "chomping" on: 26.1 skips to
> the closing parens, master doesn't.

> But it's tricky. From elec-pair.el's perspective, skipping whitespace
> means skipping whitespace characters *and* not crossing string/comment
> boundaries.  To analyse a test case very similar to yours I wrote a
> simple function (attached after my sig) to analyse just 5 characters and
> an end-of-file.

>    ( " \n " ) EOF

I think you mean " ( \n ) " EOF.  :-)

> In Emacs 26.1 I get

>   ((:character 34 :formatted "\"" :syntax
>                (7)
>                :depth 0 :string nil :last-open-parens nil)
>    (:character 40 :formatted "(" :syntax
>                (4 . 41)
>                :depth 0 :string 34 :last-open-parens 1)
>    (:character 10 :formatted "\n" :syntax
>                (0)
>                :depth 0 :string 34 :last-open-parens 1)
>    (:character 41 :formatted ")" :syntax
>                (5 . 40)
>                :depth 0 :string 34 :last-open-parens 1)
>    (:character 34 :formatted "\"" :syntax
>                (7)
>                :depth 0 :string 34 :last-open-parens 1)
>    (:character nil :formatted "EOF" :syntax nil :depth 0 :string nil
>                :last-open-parens nil))
               

> In Emacs master, I get

>   ((:character 34 :formatted "\"" :syntax
>                (15)
>                :depth 0 :string nil :last-open-parens nil)
>    (:character 40 :formatted "(" :syntax
>                (4 . 41)
>                :depth 0 :string t :last-open-parens 1)
>    (:character 10 :formatted "\n" :syntax
>                (15)
>                :depth 0 :string t :last-open-parens 1)
>    (:character 41 :formatted ")" :syntax
>                (5 . 40)
>                :depth 0 :string nil :last-open-parens nil)
>    (:character 34 :formatted "\"" :syntax
>                (15)
>                :depth -1 :string nil :last-open-parens nil)
>    (:character nil :formatted "EOF" :syntax nil :depth -1 :string t
>                :last-open-parens 5))

> Note that the newline character changed its syntax from (0), which is
> whitespace, to (15) which is generic string. But more importantly, the
> closing paren after it no longer declares to be inside a string
> according to syntax-ppss.

> Is this what you and (the majority of) cc-mode users expect? If it is,
> then this test (and probably many other ones) must be changed to reflect
> that.

Yes.  A string in C(++) mode extending over several lines is only valid
when the newlines are escaped.  The generic string syntax is partly an
artifice to get font-lock-warning-face, but is also deliberately
intended to cut the opener of the invalid string off from any subsequent
double quote.

> As a data-point, as an occasional c++- mode user, I'd much rather have
> Emacs 26's behaviour.  When faced with such admittedly invalid C, I at
> most expect M-x compile or Flymake to tell me about it, but would like
> Emacs to treat it as whitespace so electric-pair keeps functioning
> correctly.  That is, I expect Emacs to not choke my editing tools
> because I've temporarily produced syntactically incorrect code while
> editing, particularly tools designed to correct such situations.

OK.  I'll need to mull this over.

> I've also noted that whitespace-fixing tools aren't tripped by your
> change. But that's because they don't care about comment and string
> boundaries, although they could/should.  This suggests we could make
> elec-pair.el also not care about them in c++ mode, but it would only
> take us so far, because I fear worse problems would come in more basic
> elec-pair.el funtionality.

> In general, I think you should review the recent c++-mode changes. To
> illustrate, here's a new bug report without any newlines.

> 1. emacs-master/src/emacs -Q
> 2. M-x erase-buffer RET !
> 3. M-x c++-mode
> 4. M-x electric-pair-mode
> 5. insert a double quote (this inserts a closer)
> 6. insert an opening parens (this inserts a closer)
> 7. insert a double quote (this inserts a closer, but...)

> ... it additionally popups up an error:

>    c-append-to-state-cache: Scan error: "Unbalanced parentheses", 5, 1

I don't see this at all.  For me, that sequence of actions simply works,
without signalling an error.  This was on the master branch as I
committed my change today.

> The last quote becomes red. If I erase the buffer again and do the whole
> thing again, no error happens and no red quote, which is what I expect
> it to do (and Emacs 26 behaviour).

> Actually, electric-pair-mode doesn't even need to be on:

> 1. emacs-master/src/emacs -Q
> 2. M-x erase-buffer RET !
> 3. M-x c++-mode
> 5a. insert a double quote
> 5b. insert the closer quote
> 5.c go back one char
> 6a. insert an opening parens
> 6b. insert the closer, go back one char
> 7a. insert a double quote
> 7b. try to insert the closer quote

> You get the same c-append-to-state-cache error

I don't see this either.  And we both started with -Q, so it's not
something in .emacs.  Are you sure you've downloaded and build that
latest patch of mine?

> João

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).