On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie <
address@hidden> wrote:
> Hello, João.
> 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.
> > > 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?
> > 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. Instead of up-listing
to the first quote, you get an error. Now but point on the starting
quote and try C-M-f. Again, error. But only in Emacs 27/cc-mode,
probably starting from fe06f64b (that's a git commit hash).
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?
Now, you might not care for this consistency, but I personally did.
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.
> > 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*.
> > 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.
> 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. 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.
> > 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.
--
João Távora