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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 1- Make sure the programmer is aware there's a problem in its code.
>>    I.e. highlight the opening quote or the non-escaped end-of-line or
>>    something in bright red or something like that.
> Agreed.  Given this criterion, the patch is an improvement: making sure that
> lines past the first one are not highlighted suppresses the risk of
> misleading the programmer into thinking that they have a multiline-string.

The old behavior highlighted the opening (and not-closed on the same
line) quote in font-lock-warning-face, which seemed perfectly adequate.

> (This happens to me from time to time in Python, actually: I write "abc
> def" instead of """abc
> def""", and the highlighting doesn't immediately reveal the error.
> Simply not highlighting the second line would help a lot.

It's easier to highlight the unmatched opener than to try and prevent
the second line from being highlighted (and you want to highlight that
opener in any case).

>> 2- Don't try to guess what the user intended to do.
>>    Instead keep our code as simple as possible: the C code we're handed
>>    is broken, so there's no real clear "right behavior" anyway.
>
> I'm not sure whether we can afford to bail out like that — for people who
> don't use some form of structured editing, most of the code that the IDE
> ends up seeing is broken in some way (unmatched { or ", incomplete
> declarations, incorrect numbers of arguments, undeclared identifiers, etc.)

Not sure what you mean by "bail out".  Point 1 has added highlighting to
warn the user about the presence of a problem.  Short of changing the
actual code behind the user's back, there's really not much more we can
do to prevent the compiler/IDE from seeing that broken code.

> Modeling our error recovery behaviors on the one used by relevant compilers
> seems like a pretty good approach (ultimately, for the modes I maintain, I'd
> like to delegate fontification to a language server provided by the
> compiler).

Point 2 suggest to go with the simplest implementation (i.e. let the
behavior be dictated by the implementation), so if your highlighting is
provided by LSP (say), then point 2 would suggest that there's no point
trying to provide a different behavior from the one provided by the
LSP server.


        Stefan