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

[João Távora]

Alan Mackenzie <address@hidden> writes:

> Hello, João.

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

Well, I respectfully and totally disagree.  The reason we have automated
tests in Hydra is to catch unintentional breakage, not intentional
breakage.  And, IIUC that test is the only one preventing a successful
"make check".

For development temporarily unhampered by tests, I think a separate
branch is a much better alternative.  It's a very easy thing to do in
git (and in your case, trivial to merge from and back to master, given
you have near-total control over that area of code).

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

How so? Can't you just revert the commit that broke it? 

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

I think you mean "mode", in the singular form :-).

Also, it doesn't "match reality": if you open a line in a string, it
syntax highlights the remaining string as C statements, but the C parser
doesn't see C statements.  IOW, newline doesn't *really* terminate a
string in C.

> 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?

No.  If it did so, it would chomp parenthesis from non-comment regions
into comment regions, for example.

That doesn't make sense, not according to show-paren-mode, for example.

By the way, after your change, very basic commands which fall completely
outside electric-pair-mode have fundamentally changed their behaviour in
cc-mode. Here are a few, out of Emacs -Q:

* Open a line in a string, using C-o.  Sexp-navigation is now messed up
  in the whole buffer, i.e. C-M-*.  Most commads error or produce
  surprising result.  So even if the intent is to eventually add a
  backslash escaping the newline, or make it two adjacent strings by
  typing two quotes (something perfectly allowed by C).

* Inside the string, `forward-sexp' in a parenthesis of a NL-terminated
  string now errors where it would previously do its job of jumping to
  the closer;

* Also inside the string, `blink-matching-paren', on by default, also
  doesn't work as before: closing a paren on a NL-started string doesn't
  match the opener.

There are no automated tests for these things, otherwise you could be
seeing test breakage here too (and, with higher probably, you may be
seeing breakage in user's expectations later on).

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

I don't understand how this matters to the problem at hand, but
regardless, can you make a bug report demonstrating the presumed bug and
its impact so I can follow up?

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

Don't forget that the particular piece of e-p-m we're talking about is
one of the ways (arguably the easiest way) to actually fix the specific
C/C++ problem at hand for the user.  IOW it's not some random whimsical
useless thing.

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

I suppose that's a "yes".  In that case, the face `warning`, which
defaults to a very bright red, would be fine for me personally (and I'm
confident if could be made even more evident).  Also, the fact that the
remaining string is now syntax-highlighted as C statements is extremely
confusing.

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

Again, AFAIK, "mode", singular.  And, obviously, I'm not going to
special-case cc-mode in elec-pair.el: after doing some of my own
mulling, I may open a customization point for cc-mode.el to use.  So at
the very least, it's going to require some (potentially trivial) fix in
cc-mode.el, for sure.

But now that I've understood the non-e-p-m implications of your change,
I urge to at least make this configurable (if it is already
configurable, then don't mind me).

João