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

[Stefan Monnier]

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

>>   If so, what's the benefit over using string-fences?
> 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.

So the right answer was that you won't need syntax-table text-properties.

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.

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.

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

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


        Stefan