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

[Alan Mackenzie]

Hello, João.

On Sun, Jun 17, 2018 at 22:27:20 +0100, João Távora wrote:
> On Sun, Jun 17, 2018 at 9:13 PM, Alan Mackenzie <address@hidden> wrote:

> > Hello, Glenn.

> > On Sun, Jun 17, 2018 at 12:58:53 -0400, Glenn Morris wrote:
> > > Alan Mackenzie wrote:

> > > > However, the test suite (make check) threw up another discrepancy, in a
> > > > test called
> > > > electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings.

> > > Hello, is this still being worked on?
> > > The test continues to fail on RHEL 7 and hydra.nixos.org.

> > From my point of view, the bug is not being worked on this very day, but
> > has by no means been forgotten.  It has needed a period of mulling over.
> > I think João sees it the same way.


> Yes, while mulling over things is generally good, I believe the problem
> from Glenn's perspective is the nuisance of checking whether every
> test failure is something to worry about or just the thing being
> mulled over.

Yes.  But it is the master branch, where not everything can be expected
to work all the time.  I think the main thing is, we're _going_ to fix
this bug.

> So I suggest taking a quick temporary action to make the test pass
> and then think about how to do it properly.  This action could be
> disabling the test temporarily but IME that invariably buries the
> issue ad eternum. So it's better to do it in cc-mode.

Hmm.  To modify CC Mode temporarily to make 'chomp in electric-pair-mode
work would be an order of magnitude more work than "simply" to fix the
bug.  That's without disabling the handling of " in CC Mode entirely.

> Although it won't be difficult to fix, this bug is an awkward thing, and
> > will need decisions (smallish ones) to be taken.

> > My favoured method would be to alter electric-pair--skip-whitespace such
> > that a NL terminating a string (as contrasted with a NL terminating a
> > comment) would be allowed to be scanned over.


> I'm OK with adding an customization point to
> electric-pair--skip-whitespace that c-mode can customize.  But I also
> wonder whether the benefit to end-users of handling NL-terminated
> strings are worth it.  Perhaps there are indeed benefits, it's just that
> I haven't seen them argued.

OK, here goes.  Why should major modes tie themselves in knots, just so
that electric-pair-mode can work?  What CC Mode is doing is natural, and
matches the reality.  A C(++) compiler regards an unterminated string as
ending at the (first unescaped) linefeed.  It will then regard the next
line as code (not string).  If there is a subsequent ", the compiler
won't see that as a terminator for the unbalanced opening ".  CC Mode now
matches this reality, which is a Good Thing.

electric-pair-mode's chomp facility could be more rigorously coded -
sometimes it is dealing with visible whitespace, sometimes it is dealing
with syntactic properties.  Surely it should be working with visible
whitespace all the time?

I've attempted a bit of debugging.  In addition to
electric-pair--skip-whitespace, I encountered a scan-sexps in subfunction
ended-prematurely-fn of function electric-pair--balance-info, which
snagged on the end of string at EOL.

> But more importantly perhaps there are ways to reap these benefits in a
> way that doesn't require changes to e-p-m, or even better, in a way
> that benefits all of Emacs, not just c-mode.

We are talking about a corner case in e-p-m, namely where e-p-m attempts
to chomp space between parens inside an invalid string.  This surely
won't come up in practice very much.  Is it worth fixing?  (I would say
yes.)

> So, in practice, is the advantage here that the user is visually
> warned of an invalid NL-terminated string?

The user is visually informed of the reality: that one or more strings
are unterminated, and where the "breakage" is (where the
font-lock-string-face stops).  This is an improvement over the previous
handling, where the opening invalid " merely got warning-face, but the
following unterminated string flowed on indefinitely.

The disadvantage is that e-p-m is constraining major modes in how they
can use syntax-table text properties.  I think this is a problem in
electric-pair-mode, not in CC Mode.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).