Re: CC Mode and electric-pair "problem".

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sun, Jul 01, 2018 at 00:02:56 -0400, Stefan Monnier wrote:
> >> So let's look at the technical issues:
> >> You suggest introducing a new syntax-table thingy similar to > but for
> >> strings.  Let's call it ]
> > As I noted above, I have implemented it as another flag, `s'.

> Better, yes.

> > This is simple with the flag `s'.  NL would thus have end-comment syntax
> > _and_ the `s' flag.  In scan_lists, back_comment will be tried before
> > what I'm calling `back_maybe_string', since being a comment ender must have
> > precedence over being a string terminator.

> Why?    How 'bout:

>     char foo[] = "some unterminated // string

Bug compatibility with the current scan-sexps.

> > String-fence stopped the 'chomp facility of electric-pair-mode
> > working properly (for the currently accepted value of "properly").

> I suspect that it'll be easier to fix electric-pair-mode.

This would be my preferred option too, but it's not easy.

> But the downside is that every time we scan backwards over a newline
> we'll have to pay the extra cost of checking whether it's maybe
> closing an unterminated string.

Hmmm.  Yes, this could increase the backward scanning time quite
substantially, but we already do this for back_comment, though.  It
might be unacceptable.

A possibility would be to apply the `s' flag only in a syntax-table text
property applied to the newlines of unterminated strings.

> I think such a "string terminator" thingy would be valuable if it were
> used/needed for *valid* code.  But introducing such complexity just to
> tweak the handling of invalid code doesn't seem like a good tradeoff
> at all.

I disagree.  Whilst editing code, it is in an invalid state nearly all
the time.  It is our job to present the user with the best possible
display for this dominant state.

> > That's what I'm doing with `s'.  The extra complexity in syntax.c
> > doesn't seem all that bad at the moment.  back_maybe_string is currently
> > 137 lines long (including a macro analogous to INC_FROM, and a lossage:
> > clause modelled on the one in back_comment)), compared with
> > back_comment's 289 lines.  I'm planning on committing this new code to a
> > branch in the next few days, then you can judge better whether the new
> > facility is worth it.

> I can't imagine how seeing the code could change my opinion on whether
> it's worth it.

I would hope you would weigh up the small additional complexity against
the new features it brings, and reach a balanced judgment, rather than
dismissing the new idea without consideration.

> > "S-T-NG" may be fine for Emacs 28 or 29, but the syntax table is what we
> > have, and what we must work with in the short term.

> We'll never get to "S-T-NG" if we keep it for the future.

You see the need for it, and have at least some vague notion of what it
should look like.  I don't.  Get hacking!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).