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

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

>> >> But we usually don't make any effort to guess what the intended
>> >> closest valid state might be, except where the user is actively
>> >> editing the text (e.g. by proposing completion candidates for
>> >> identifiers).
>> > There's no need to guess.  The compiler defines the state, namely that
>> > the (invalid) string ends at the EOL, and what follows is non-string.
>> The compiler just makes an arbitrary choice, ....
> No.  The compiler has no choice here.  Or does it?

Of course it does.

> Can you identify any other sensible strategy a compiler could follow?

It could look for the next (closing) " and if it's not on the same line
signal an error about "invalid multiline string" (or "unterminated
string" if it bumps into EOF).  GCC used to do just that (without even
signaling an error) IIRC.

> There may or may not be a unique "intended valid state".  I don't think
> it's a helpful concept - it suggests that the states a buffer is in most
> of the time are in some way unimportant.  I reaffirm my view that Emacs
> should present optimal information about these normal (invalid) states,
> and that they are very important indeed.

I'm not sure you can define "optimal" without defining "intended valid
state" in this case.

> That's a good idea.  I think it's clear that such a merge could be done.
> But it would need a lot of detailed painstaking work.

From what I remember of back_comment (not very fresh, to be honest),
I think there's a good chance it would be pretty easy, actually (at
least easy in terms of the resulting patch being short: it may take
some time to come up with the patch, OTOH).

> With the `s' flag in place: 1.9489 seconds.
> Without the `s' flag:       1.3003 seconds.

Wow, I must say I expected a significantly lower overhead.


        Stefan