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

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie <acm@muc.de> wrote:

> > [did you mean to copy bug-gnu-emacs@gnu.org, or emacs-devel@gnu.org?
> > I'm assuming the latter and correcting]
> No, it's a bug, therefore I submitted a bug report.

You should use the X-Debbugs-CC feature then (and why not continue
in the existing bug 36423?)

Anyway, I insist this matter be brought to emacs-devel because it's a
followup to a discussion that started there but never reached a
suitable conclusion. For that reason, and because I provide a
workaround for the bug  at the end of  this message, I'm cross-posting
this one mail to both the bug list and emacs-devel.

> > The arguments _against_ NL-terminated strings is that they (1) break
> > longstanding features such as sexp-based navigation (e.g. `up-list`
> > and friends) for modes such say, `js-mode` and (2) break features
> > that expect this to work, most notably electric-pair-mode.
>
> This isn't true.

What "isn't true"? Have those features broken or not? They worked
before the fe06f643b commit and don't work after the commit. It
sounds quite unrefutable to me.

> If those other feature no longer work with an up to
> date Emacs, they should be fixed.

I've stated this repeatedly in the life of this discussion: it's not just
about
electric-pair-mode. If you try to M-x up-list from a multi-line string in
emacs 26.1 it works just as well in js-mode and c++-mode.  In emacs
master it does not in c++-mode. Same with forward-sexp on the starting
delimiter, etc.

> The fontification that CC Mode does is natural and helpful, and users
> haven't complained about it (except when there've been bugs).

Yes, users haven't complained except when users have complained.

> There have
> certainly been no complaints about using font-lock-warning-face for the
> invalid string delimiters, and font-lock-string-face for valid ones.

That's because providing this annotation is perfectly fine.  The problem
is providing it _at the expense of other features_. And _that's_ what
they've complained about: an average user has no obvious way of
telling that the particular implementation of the red annotation thingy
is guilty of breaking his C-M-u or his electric-pair-mode.

He/she might even judge the latter more vital than said red thingy
, an annotation which he/she will get by other means if using
very popular packages such as flycheck, or flymake, or eglot, or
lsp-mode, etc. These normally call the compiler directly on the
source code and highlight those and many other errors.

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? And if you are,
are you also absolutely sure you need to put it in the code and
and not provide an easy way to turn it off?

> For this, I think we would both rather that you amend elec-pair.el rather
> than me.

I'll be "mulling this over". There are potentially many other points of
breakage that would need such an indirection, and doing that to serve
just a particular cc-mode quirk doesn't sound priority to me.

In the meantime, let others chime in.

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)

I had something more elaborate in my setup but just this
seems to fix it in my testing.

There is a also a very promising variable, c-multiline-string-start-char,
that I think would be a good candidate for customizing this, but I
haven't messed with it enough. Just setting it from .emacs doesn't
do the trick. Perhaps in a mode hook?

--
João Távora

[-- Attachment #2: Type: text/html, Size: 5107 bytes --]