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

[Alan Mackenzie <acm@muc.de>]

Hello, João.

On Wed, Jul 03, 2019 at 10:28:11 +0100, João Távora wrote:
> On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie <acm@muc.de> wrote:

> > I didn't know about the former, and as for the bug, it is a different
> > bug with differenct causes from #36423.

> If you say so... I stopped cross-posting, you probably should, too.

You've hijacked this bug report for your own purposes.  That is not a
gentlemanly thing to do.  Why could you not have started your own
thread?

Are you going to attend to bug #36474, which was the proper topic of
this thread?  Or would you like me to?

> > > > This isn't true.

> > > What "isn't true"? Have those features broken or not?

> > They may well be broken.  CC Mode hasn't broken them.  They made
> > invalid assumptions, which turned out to be unjustified.

> C-M-u (up-list) made an invalid assumption?

No.  You made an invalid assumption in trying to use it.

> > > They worked before the fe06f643b commit and don't work after the
> > > commit. It sounds quite unrefutable to me.

> > I don't know what you're talking about.
> > I've just tried these in a multiline string in C++ Mode.  Both up-list
> > and forward-sexp work just fine.  I don't know what you're doing.

> Start emacs -Q, open a buffer with a double quote followed by some
> newlines and then another another double quote.  Now put the buffer in
> C++ mode and type C-M-u from between the quotes.

Ah, I see.  You said you'd done this from a multiline string.  What you
have constructed is not a multiline string, it is two invalid string
delimiters unconnected with eachother with extraneous matter between
them.

> Instead of up-listing to the first quote, you get an error.  Now put
> point on the starting quote and try C-M-f.  Again, error.

It works for me.  It moves to the end of the initial invalid string.

> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
> a git commit hash).

I'm fully aware it's a git commit hash.  Funnily enough, I don't
memorise such hashes, so if you wish to draw my attention to some
commit, please have the decency to give me its date, and the summary
line of its commit message, instead of expecting me to do your work to
make your point.

> Now repeat this experiment. Let me make a little ASCII table:

>                      WORKS    DOESN'T

> emacs 27/c++mode                X
> emacs 26.1/c++-mode   X
> emacs 27/js-mode      X
> emacs 27/ruby-mode    X
> emacs 27/(many)       X

> Do you know what I'm talking about now?

Yes, I do.  Now try the following.  In your C++ buffer, make a comment,
and put an open parenthesis inside it.  After the comment put a matching
close paren.  From the opening paren try C-M-f.  Guess what?  You get an
error, just like you do in your case with the broken strings.

> Now, you might not care for this consistency, but I personally did.

CC Mode has always put a strong emphasis on correctness and accuracy.
You're complaining that a dubious trick borne of incorrectness no longer
works.  I don't think you have a strong position to complain.

> I've always had my methods of navigating code with unterminated strings,
> with _or without_ electric-pair mode and your cc-mode changes broke
> this workflow.

I think, perhaps, you encounter such broken strings extremely rarely,
and you're making a big song and dance over a relatively minor matter.

> > > lsp-mode, etc. These normally call the compiler directly on the
> > > source code and highlight those and many other errors.

> > Irrelevant.

> > > On the other hand, if what you want is the red annotation, are you
> > > absolutely sure there isn't a better way to get it?

> > No, I'm not.  That's why I invited you to come up with a better way, if
> > you can.

> I gave your one exactly one paragraph ago, which you called dismissed as
> "irrelevant". *shrug*.

*shrug* as much as you like.  You know full well what I meant when I
asked you to suggest an alternative.  So please stop being so damned
evasive and answer the point: can you suggest some other mechanism by
which CC Mode can create the required font-locking?  If you can, and
it's workable, we all win.

> > > I'll be "mulling this over". There are potentially many other points
> > > of breakage
> > "Potentially" many?  So far, there is precisely one, in
> > electric-pair--unbalanced-strings-p.

> What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same
> problem?  Maybe, I don't know.  Certainly the broken C-M-u and C-M-f,
> aren't the same problem.

C-M-u and C-M-f aren't broken.  You just have unreasonable expectations
of them.

> > No, you'd be cleaning up your code, to conform with the reality that in
> > 2019 major modes use syntax-table text properties.  Features from CC
> > Mode have a habit of migrating to the Emacs core.

> It's not "my" code and I won't be bullied into making changes I don't
> agree with.

If anybody's the bully around here, it's not me.  I found a minor bug in
electric-pair-mode, diagnosed it, and reported it.  Then I found myself
engulfed in your immoderate tirade, trying to bully me into a major
restructuring of CC Mode so as to suit your somewhat unreasonable
wishes.

As far as I can make out, you are the maintainer of electric-pair-mode,
and you seem to be refusing to fix a bug, not even a difficult bug.  Are
you going to fix bug #36474 or not?

> Things worked fine until you added a feature in June 2018 that broke
> them.  You refuse to even let the user disable that feature or
> consider alternatives.  That's simply not reasonable to me.

Like you declining even to look at bug #36474?  Correctness in CC Mode
is not an optional feature - it goes to the heart of the mode.

> > > Also, in the meantime, for a user that is bothered by this bug,
> > > I'd recomend to put something like this in his/her .emacs file:

> > >   (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)

> > It's free software, but that's a stupid thing to do.

> I'd ask you to actually give an argument instead of an insult, but I've
> been on this hamster wheel before, so never mind.  It works quite well.

Making random changes to the innards of a program tends to break things.
Will that do you instead?

> --
> João Távora

-- 
Alan Mackenzie (Nuremberg, Germany).