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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> some people, including me, find the insertion of characters they haven't
> typed (aside from tabs/spaces for indentation) annoying.

Don't think of it as a character, think of it as "a special syntax-table
string-closer that's not really in the buffer": it will be automatically
removed when you fix the unterminated string anyway.

For that reason it's very different from electric-pair-mode: the " char
it adds is not meant to save you from typing typing the closing string
delimiter, it's just a technical device to bound temporarily the extent
of the string until the time you close it.

> It's good that there are minor modes that can do this, but it's not
> the way to solve the current difficulty.

Maybe the sample implementation I provided is not quite right, but
I think the approach of temporarily inserting a " instead of messing
with syntax-table properties is actually much closer to the current
CC-mode behavior than to electric-pair-mode.

> But it doesn't really address the problem.  That problem is how to
> fontify unterminated strings (in both senses of the word "how").

An unterminated string can only occur in an invalid piece of code.
To the extent that invalid code has no clear meaning, there's no way
to know what is really the "right" behavior.

My point of view is that Emacs should focus on behaving as correctly as
possible for valid code.  The only effort worth doing w.r.t invalid code
is to avoid doing something clearly harmful and to help the user make
the code valid again.  Anything further than that is time that would be
better spent improving the handling of valid code.

I don't see any concrete benefit (for the user) of the new behavior over
the old (or the reverse for that matter).  Either behavior is equally
good and which behavior is better will depend on things which Emacs
cannot know unless the user explicitly tells us.

> Up till now, Emacs hasn't bothered - it just allows these strings, and the
> subsequent buffer portion, to be fontified randomly.

It's not random: it's arbitrary.  The new behavior is also arbitrary.

AFAIK you have no statistical data to claim that your new behavior is
more often better than worse (and even less data to claim that the
difference is significant).  So it's mostly different.

> I think such a string should have string face up till the first
> unescaped newline (in modes where escaped NLs are required for
> multiline strings).

Yes, we saw that.  Some other users agree.  Yet others disagree.

Personally, as a user, I don't really care which behavior I get: it's
a rare transient situation which I'll fix soon anyway, whether Emacs
tells me about it or not.

OTOH, there is very concrete evidence that the new behavior is worse in
the sense that it adds complexity to the code and (as expected)
introduces bugs.

To me, this is a bad tradeoff.

> I can't see any other way anybody would want such a construct
> to be fontified.

That's just a lack of imagination on your part.  Tho it also means you
haven't made the effort to appreciate some of the scenarios people have
presented here where the old behavior is preferable.


        Stefan