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

["João Távora" <joaotavora@gmail.com>]

Alan Mackenzie <acm@muc.de> writes:

>> 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).
>
> It's possible, but it's a hassle; it's outside of normal workflow,
> therefore involves getting into git's execrable documentation.

hehe. lol.  OK, but really you should checkout out branches, they're all
the rage these days :-)

>> > 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 :-).
>
> No.  CC Mode comprises lots of modes, not all of them maintained by me.
> But even aside from that, CC Mode has often been a pioneer, developing
> new techniques, which the rest of Emacs has then followed.  Examples are
> hungry deletion and electric indentation.

But they are all children of cc-mode.el right?  I meant singular as in,
afaik, nobody else independently thought of doing that besides you.

>> 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.
>
> We could argue about words like "terminate" indefinitely.  What I think
> is incontrovertible is if you open a line in a string, the portion after
> that opening is not part of the string opened on the line above.  The
> new fontification reflects this fact.

OK, but now reflects it reflects something that is also wrong (they're
not statements either), but to a much greater degress. And on top of
that with many more adverse side effects, of which only one is breaking
e-p-m mode.

>> > 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.
> But it could use the strategy of determining the end of any comment,
> then using non-syntax facilities for traversing the space up to that
> end.  Or something like that.

I'll look into "something like that".

> I've tried this, obviously, but as far as I'm aware, the operation of
> C-M-* is correct for the (now syntactically incorrect) buffer.  If you
> can give me a concrete example, I can look at it and correct it.

It's now much hard to select the whole invalid string.  It used to be a
matter of C-M-u C-M-SPC.  To use query-replace in the region, for
example.

>> * 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.
>
> Do you mean a NL-ENDED string?  I see matching here.  If you can be more
> precise about the failure, I can look at it.

No, I mean the closer.  You and the mode don't consider that a string
anymore, but you used to, and I still want do.

>> 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).
> No, these things are not all intended functionality of Emacs, they're
> just side effects of the way the real functionality was implemented.

These accidents, as you have them, work just fine in just about any
other mode I can imagine.  And they worked just fine in c-mode up until
your change.

>> > 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?
> I attempted to see how difficult it would be to modify elec-pair.el to
> cope with unconstrained text properties in buffers.  This was the second
> problem I came up against.

Well, programming is a continuous problem in general.  If I understand
correctly, the thing you're trying to change is an implementation detail
of electric-pair-mode, not part of its contract, right?  If, on the
contrary, you think it is a bug, let me know.

>> > 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.
> It's not useless, but it's rare - it's three things happening all at the
> same time, namely a broken string, pseudo-matching parens and space
> between them.  This isn't going to happen very often.  I'd wager that
> broken strings (two "s with non-escaped NLs between them) in themselves
> are quite rare.  But I still think it should be fixed.  :-)

Well, it's handling the rarities that makes Emacs stand out.

>> > 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.
>
> Why?  They are now C statements, and would be handled by the compiler as
> such.

Clarify "would". Because this doesn't compile.  My compiler doesn't even
seem to look at anything after the unterminated string:
    
   int main () {
      printf("foo
             ); 
      printf("bar");
      return 0;
     }


>> > 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.
>
> See above.  Perhaps it's worth noting that AWK-Mode has used this method
> of indicating invalid strings for around 15 years, now.  There have
> never been any complaints about this from users.

But they weren't ever exposed to the previous behaviour, right?  And
also, I believe that there is some discrepancy between the number users
of AWK and C, the complexity of the average program, etc...

>> 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).
> Make correct fontification configurable?

For some newfound value of "correct", surely...

> There remains the problem of making chomping parens inside a broken
> string work.  I honestly think that modifying elec-pair.el is the way to
> go, but I'm open to suggestions of alternative strategies that CC Mode
> could follow to get the same fontification, that wouldn't require
> modifying elec-pair.el.

As I said, I will look into providing an entry point in elec-pair.el for
this.

Didn't you mention earlier pike-mode and d-mode? Quoting your earlier
message:

    > Pike Mode has a special feature whereby a string starting with #"
    > is a multiline string.  I think in D Mode (not maintained here),
    > strings simply are multiline, and there is no such thing as an
    > escaped EOL.

    > The writer of the mode sets the CC Mode "language variable"
    > c-multiline-string-start-char to the character # for Pike Mode, or
    > some non-character non-nil value for D Mode (usually t, of
    > course).

Can't I do this to my c/c++ mode?  Would't this be a way to get the old
behaviour back.  Perhaps it could be be let-bound in tests, also.

João