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

[Alan Mackenzie <acm@muc.de>]

Hello, João.

On Wed, Jul 10, 2019 at 13:10:45 +0100, João Távora wrote:
> On Wed, Jul 10, 2019 at 11:32 AM Alan Mackenzie <acm@muc.de> wrote:

> > 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 <acm@muc.de> 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.

> You misunderstood me. What I said "just doens't happen" is "fontify
> arbitrarily large pieces".

OK.  Sorry about that.

> > 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.

> Even if electric-pair-mode users are a minority users of autopairing
> solutions such as smartparens are most definitely not. Every modern
> editor has one of those.

I'll believe you, though I don't know what you mean by smartparens.

> The very same applies to those users. But even if those users are a
> minority (< 50%), it still doesn't justify breaking long-held behavior
> that they expect.

Or are we talking about fixing long standing breakage they've had to
tolerate?  At least two people on this list have said they welcome the CC
Mode style of fontification of invalid strings.

> > > 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.

> Precisely. I say it _doesn't_ know and _can't_ know. So any guess, such
> as the one you're taking, that it's an invalid string, is wrong some
> percentage of the time.

Neither CC Mode nor I guess.  "We" both use a definition of "string" that
obviates guessing.  (See next paragraph.)

> > 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.

> The compiler doesn't edit code. It's irrelevant how it views the lines
> after the error, so long as it hightlights the error in the correct
> line.

What's that got to do with it?  If you don't like CC Mode's definition of
a string, propose an alternative here, a non-vague alternative, and we
can discuss it.

> > > 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.

> Stepping carefully on the terms, you have made two patches since
> this "problem" happened:

> 1. One to restore the previous e-p-m behaviour in cc-mode
> 2. A long patch devised "just for me" to restore previous C-M-behaviour

Yes.  There were bugs in the interface between CC Mode and
electric-pair-mode, and half of us had to sort these out.  It's a good
job that one of us was able to step up, and diagnose and fix this.

As for 2, what you want there, as I keep saying, is bogus.  You want to
treat two syntactically disjoint "s as though they enclosed a string.
Although this is bogus, I have some sympathy with people who want to do
this, on the grounds that it "worked" in the past.  But it is
fundamentally bogus.

> The necessity of such patches, and the fact that patch 2 is likely buggy,
> according to you, can be seen, in my opinion, as an expression of "harm".

Must you be like that?  That patch is not "likely buggy", any more than
any other patch.  There is one particular bug in it, a very obscure
situation, where a raw string's identifier which contains "s gets
confused with another raw string when the defining delimiters are damaged
in a particular fashion.  Not something you're liable to stumble over,
but my integrity prevents me from representing the patch as bug free.  It
will be getting fixed nevertheless.

As you acknowleged in another post, that patch took some hours to write.
Would you please, as the person clamouring for it, try it out now and
give me appropriate feedback.  I would rather get that feedback before
committing it to savannah than afterwards.

> > > 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.


> So the "gross distortion" is that you think it's absolutely necessary that
> the error be annotated both at string start and invalid string end?

Yes.

> Only one of them is are totally wrong for you. Is that it, the thursday
> thing?

Sorry, I can't parse that.

> Doesn't seem so important for me, but if it were, the flymake backend
> I proposed can highlight wherever you most desire. I don't know about
> Stefan's solution, though.

> Does the compiler tell the user about both locations?

I don't know.  With having the correct highlighting in CC Mode, invalid
strings get corrected before being submitted to the compiler.  ;-)

> > > 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.


> So can you summarize, for my benefit:

> - What are the drawbacks of Stefan's solution?

It doesn't, at least without an awful lot of effort, fontify an invalid
string in the correct CC Mode fashion.  It would leave an arbitrary
amount of text after the end of an invalid string fontified with
string-face.

> - What are the drawbacks of my flymake-based soluion?

It's not part of CC Mode.  It would involve loading another package, and
likely would be slower than CC Mode's fontification.  It would not be
well integrated with CC Mode, and would possibly need a lot of work to
make it work properly.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).