On Wed, Jul 10, 2019 at 3:03 PM Alan Mackenzie <acm@muc.de> wrote:
> I'll believe you, though I don't know what you mean by smartparens.

See https://github.com/Fuco1/smartparens.

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

I wasn't talking about that, I was talking about the cc/e-p-m related bug
that a user reported, and the C-M-stuff that I use.  This is a behavior
in emacs that probably existed since cc-mode was first created up
to last year.

But, we can start talking about that "tolerated breakage", by
which you probably mean what has been recently described here as
"blinking" a lower portion of the screen between string/non-string
fontification for people that don't use a delimiter-pairing solution.
And we could start by examining solutions that:

1. Don't have any drawbacks to e-p-m and C-M-navigation;
2. Fix it in all of Emacs, even in modes that _do_ have multi-line strings;

We've established that your cc-mode solution does not verify 1 (and by
definition it does not verify 2).

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

Very well: I want the previous CC Mode's definition of a string, before your
changes of June 2018. This is so non-vague that it's even coded up in
the git repository. At the very least  I want to be able to switch to
it, and also think it should be the default, because it's (quite probably)
the definition that has existed from cc-mode's inception in 19xx up to
June 2018.

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

That's a heartwarming comment, because it's always heartwarming
that the person who fixes it was the one that broke it in the first
place. Pardon, "committed actions that made it work differently than
it did before, causing a bug report".

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

Two "syntactically disjoint" double quotes in C are _always_ bogus. There
can be 0 such occurrences in a correct C program. The only job the compiler
has is to not compile the program and presumably signal the error. The
editor should do so, too. It _doesnt_ need to do it by implementing
exactly the syntax of the C standard, because the editor is not not
a compiler.

And that's the sensible approach that Emacs has taken since a
long time.

Again, you may argue that with it comes a "blinking" problem for those
that don't use quote-pairing solutions. I will agree. And that problem
happens with comments, too, and in many many other modes. It's not
exclusive to cc-mode.

> Must you be like that?  That patch is not "likely buggy", any more than
> any other patch.

You said "the enhancement is not yet bug free". That makes it a
least "likely buggy".

> There is one particular bug in it, a very obscure

Oh, then I think that makes it 100% surely buggy!

> As you acknowleged in another post, that patch took some hours to write.
> Would you please, as the person clamouring for it,

I thanked you for your great unsolicited efforts, but now I must solicit
a final one: where exactly did I "clamour" for it? I told you from the
beginning that the problem doesn't affect me in particular. I also don't
remember having encouraged you to persist in that particular
solution for other users sake.

Indeed I hope it is never installed, because frankly, breaking
the no-disparagement rule, it looks ghastly. Seriously, look
at it.

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

OK. Since I don't know Stefan's solution, I won't refute. But I will
ask:

1. What is "the correct CC Mode fashion" these days?
2. What is the problem with the second part. Is it the "blinking"
problem that I agreed to earlier? Or is it something else? Are you
preoccupied that the syntax of an invalid program as shown in
cc-mode is exactly like some compiler's internal view of it?

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

It already works properly. In many cases it does not need to be "integrated"
with the major mode at all. Also probably faster, depending on whether you
launch the compiler process asynchronously (which is the default).  I'd say
you have to try it. It doesn't need to be flymake, you can ask folks about
flycheck, too, which many people prefer (https://www.flycheck.org/en/latest/
).

João