Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

[Alan Mackenzie]

Hello, João.

On Tue, Jul 09, 2019 at 19:53:17 +0100, João Távora wrote:
> On Tue, Jul 9, 2019 at 7:26 PM Alan Mackenzie <address@hidden> wrote:

> > Not really.  The overwhelmingly most common use case is typing in a
> > short string which fits on one line, when the next line is (almost)
> > always a line of code.  It is not sensible to fontify arbitrarily large
> > pieces of code as a string, just because the user hasn't yet reached her
> > closing double quote.

> You think that's the "overwhelmingly" most common use case. But if
> the user is using electric-pair-mode (the thing you just "fixed", the thing
> that the original author of the bug is using), it just doesn't happen.

Even if electric-pair-mode is enabled, the overwhelmingly most common
use case will still be a short string which fits on a single line, and
the next line will still (almost) always be a line of code.

> That's not because those users don't insert strings in their code, but
> because the closing double quote is inserted for them automatically.
> And so no arbitrarily large piece of code is fontified as a string _in
> the particular case of adding, say, a printf("Hello world"); to the
> start of a function.

That's fine for users of electric-pair-mode, but that's a minority
sport.  Many, likely most, users don't use that mode.  For that
majority, CC Mode no longer fontifies arbitrarily large pieces of code
as a string.

> Now if you don't use electric-pair-mode or another paren-matching
> solution you will see the common blinking, precisely because the major
> mode doesn't know if the user is keeping a closing quote in his
> "mental stack".

With all due respect, I think this anthropomorphic view of major modes
supposedly "guessing" what the user wants is wide of the mark.  In C
Mode, a string starts at an opening ", and stops at the next " or
unescaped NL.  That's how a compiler handles it.  It's that simple.

> All that Stefan is saying is that you are providing for this group of
> people, but that there is another group of people for which not only
> the functionality you are developing isn't useful, but also
> potentially harmful.

I fail to see this harm.

However, there is the possibility of improving the handling of
multi-line strings in CC Mode, most notably by modifying
c-context-line-break automatically to insert backslashes, and making M-q
handle backslashes properly (which it doesn't do at the moment).

> We all agree that if an unterminated string occurs, be it accidentally
> by the deletion of a closing quote, or transiently (because the user
> hasn't downloaded his "mental closing quote"), the matter should
> be annotated on that line.

I don't agree.  Or rather, that characterization is a gross distortion
of my take on the matter, which I stated last Thursday.  This is the
passage which Stefan refuses to reply to, or even acknowledge I wrote:

>> The error is clear: There is an opening quote without a matching
>> closing quote.  The former part of the error is at the opening quote,
>> so we must indicate its position somehow, most simply by marking it
>> with warning-face.  The latter part of the error happens at the first
>> unescaped EOL; this is what defines the string as invalid.  We must
>> indicate this position as well, and the best way of doing this is
>> terminating the string-face at that position.

>> It is not arbitrary.  We are not trying to guess the intention of the
>> user; we are pointing out the objective error.


> There are multiple simple solutions that do that, with no perceived
> drawbacks. Please consider some of them.

These simple solutions all have drawbacks.  I'd already considered them,
or several of them, before arriving at the current solution for CC Mode.

What I think the real issue here is that it is difficult to adapt other
major modes to follow CC Mode's lead, since they are too tightly
constrained by the syntax-propertize-function/syntax-ppss mechanisms.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).