all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: Emacs developers <emacs-devel@gnu.org>,
	Tino Calancha <tino.calancha@gmail.com>
Subject: Re: CC Mode and electric-pair "problem".
Date: Thu, 31 May 2018 17:28:41 +0000	[thread overview]
Message-ID: <20180531172841.GB24752@ACM> (raw)
In-Reply-To: <87bmcvbygg.fsf@gmail.com>

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



  reply	other threads:[~2018-05-31 17:28 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22  7:42 [Emacs-diffs] master bb591f139f: Enhance CC Mode's fontification, etc., of unterminated strings Tino Calancha
2018-05-22 17:40 ` Alan Mackenzie
2018-05-22 19:21   ` João Távora
2018-05-22 19:34     ` Eli Zaretskii
2018-05-22 20:25       ` João Távora
2018-05-22 22:17         ` João Távora
2018-05-23 14:52           ` Eli Zaretskii
2018-05-23 20:46     ` Alan Mackenzie
2018-05-23 21:12       ` João Távora
2018-05-23 23:21     ` Michael Welsh Duggan
2018-05-31 12:37 ` CC Mode and electric-pair "problem". (Was: ... master bb591f139f: Enhance CC Mode's fontification, etc., of unterminated strings.) Alan Mackenzie
2018-05-31 16:07   ` CC Mode and electric-pair "problem" João Távora
2018-05-31 17:28     ` Alan Mackenzie [this message]
2018-05-31 18:37       ` João Távora
2018-06-02 13:02         ` Alan Mackenzie
2018-06-03  3:00           ` João Távora
2018-06-17 16:58   ` Glenn Morris
2018-06-17 20:13     ` Alan Mackenzie
2018-06-17 21:07       ` Stefan Monnier
2018-06-17 21:27       ` João Távora
2018-06-18 10:36         ` Alan Mackenzie
2018-06-18 13:24           ` João Távora
2018-06-18 15:18             ` Eli Zaretskii
2018-06-18 15:37               ` João Távora
2018-06-18 16:46                 ` Eli Zaretskii
2018-06-18 17:21                   ` Eli Zaretskii
2018-06-18 23:49                   ` João Távora
2018-06-19  2:37                     ` Eli Zaretskii
2018-06-19  8:13                       ` João Távora
2018-06-19 16:59                         ` Eli Zaretskii
2018-06-19 19:40                           ` João Távora
2018-06-18 20:24                 ` Glenn Morris
2018-06-19  2:03                   ` João Távora
2018-06-18 15:42             ` Alan Mackenzie
2018-06-18 17:01               ` João Távora
2018-06-18 18:07                 ` Yuri Khan
2018-06-18 22:52                   ` João Távora
2018-06-18 18:08                 ` Alan Mackenzie
2018-06-18 23:43                   ` João Távora
2018-06-19  1:35                     ` João Távora
2018-06-19  1:48                   ` Stefan Monnier
2018-06-19  3:52                     ` Clément Pit-Claudel
2018-06-19  6:38                       ` Stefan Monnier
2018-06-20 13:48                         ` Clément Pit-Claudel
2018-06-26 16:08                     ` Fontifying unterminated strings [was: CC Mode and electric-pair "problem".] Alan Mackenzie
2018-06-26 20:02                       ` João Távora
2018-06-28 23:56                       ` Stefan Monnier
2018-06-29  0:43                         ` Stefan Monnier
2018-06-18 22:41                 ` CC Mode and electric-pair "problem" Stephen Leake
2018-06-19  0:02                   ` João Távora
2018-06-19  3:15                   ` Clément Pit-Claudel
2018-06-19  8:16                     ` João Távora
2018-06-19  5:02                 ` Alan Mackenzie
2018-06-20 14:16                   ` Stefan Monnier
2018-06-26 18:23                     ` Alan Mackenzie
2018-06-27 13:37                       ` João Távora
2018-06-29  3:42                       ` Stefan Monnier
2018-06-30 18:09                         ` Alan Mackenzie
2018-07-01  3:37                           ` Stefan Monnier
2018-07-01 15:24                             ` Eli Zaretskii
2018-07-06 21:58                             ` Stephen Leake
2018-07-01 15:57                           ` Paul Eggert
2018-06-27 18:27                     ` Alan Mackenzie
2018-06-29  4:11                       ` Stefan Monnier
2018-06-30 19:03                         ` Alan Mackenzie
2018-06-30 19:29                           ` Eli Zaretskii
2018-06-30 20:14                             ` Alan Mackenzie
2018-07-01  3:50                               ` Stefan Monnier
2018-07-01  9:58                                 ` Alan Mackenzie
2018-07-01 11:22                               ` João Távora
2018-07-01 15:25                                 ` Eli Zaretskii
2018-07-01 15:22                               ` Eli Zaretskii
2018-07-01 16:38                                 ` scratch/fontify-open-string. [Was: CC Mode and electric-pair "problem".] Alan Mackenzie
2018-07-08  8:29                                   ` Stephen Leake
2018-07-15  9:00                                     ` Stephen Leake
2018-07-15 15:13                                       ` Eli Zaretskii
2018-07-15 18:45                                         ` Alan Mackenzie
2018-07-16  2:23                                           ` Indentation of ?: in C-mode (was: scratch/fontify-open-string. [Was: CC Mode and electric-pair "problem".]) Stefan Monnier
2018-07-16 14:18                                             ` Eli Zaretskii
2018-07-16 15:54                                               ` Indentation of ?: in C-mode Stefan Monnier
2018-07-15 16:56                                       ` scratch/fontify-open-string. [Was: CC Mode and electric-pair "problem".] Alan Mackenzie
2018-07-17  3:41                                         ` Stephen Leake
2018-07-01  4:02                           ` CC Mode and electric-pair "problem" Stefan Monnier
2018-07-01 10:58                             ` Alan Mackenzie
2018-07-01 11:46                               ` João Távora
2018-07-01 16:13                               ` Stefan Monnier
2018-07-01 18:18                                 ` Alan Mackenzie
2018-07-01 23:16                                   ` Stefan Monnier
2018-07-02 19:18                                     ` Alan Mackenzie
2018-07-03  2:10                                       ` Stefan Monnier
2018-06-26 18:52                   ` Alan Mackenzie
2018-06-26 19:45                     ` João Távora
2018-06-26 20:09                       ` Alan Mackenzie

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=20180531172841.GB24752@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=tino.calancha@gmail.com \
    /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.