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

[Alan Mackenzie]

Hello, Eli.

On Sat, Jun 30, 2018 at 22:29:12 +0300, Eli Zaretskii wrote:
> > Date: Sat, 30 Jun 2018 19:03:27 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: Clément Pit-Claudel <address@hidden>,
> >     Stephen Leake <address@hidden>,
> >     João Távora <address@hidden>,
> >     address@hidden

> > I am in the middle of writing a trial implementation (code speaks louder
> > than words).  Thus far, it has already worked in shell-script-mode
> > (which required a one-line change, this:

> >     -       ?\n ">#"
> >     +       ?\n ">#s"

> > the new `s' flag is how I've constructed it, so far).

> > > But that's for Eli to judge.

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

> > > - This implies we'll need a new C-level function `back_string` to jump
> > >   backward over such a ]-terminated string, corresponding to
> > >   back_comment.

> > Yes.

> > >  `back_comment` has proved to be rather nasty, so while
> > >   we can learn from it, part of what we learn is that jumping backward
> > >   over such things is much easier ....

> > much less easy.  :-)

> > >   .... than jumping forward, so this
> > >   innocuous ] will be more costly than might meet the eye.

> > It requires the new function, which at the moment seems somewhat less
> > complicated than back_comment, and this requires to be called from
> > scan_lists.

> > > - In CC-mode, \n already has syntax > so it can't also have syntax ]
> > >   How do you intend to deal with that: will you mark those few \n that
> > >   terminate strings with syntax-table text-properties?

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

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

> > > - Another approach would be to make it possible to mark \n as both ] and
> > >   > at the same time, which would make the CC-mode feature much cleaner
> > >   (no need to muck with syntax-table text-properties) but the cost of
> > >   yet more complexity in the syntax.c code.

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

> Could you please recap what problem(s) you are trying to fix with
> these changes?  (I'm sorry for not following, but this thread spans
> two months and many long messages with several days in-between.  It's
> hard to keep focused on the main issues.)

Sorry.  That's just the way things go, sometimes.

The initial problem I tried to solve was for CC Mode source files with
things like:

    char foo[] = "foo
    char bar[] = "bar";

Historically, the missing " on "foo has caused subsequent lines to have
their string quoting reversed.  This is not good.

A recent series of CC Mode commits "solved" this by putting string-fence
syntax-table text properties on the " and the NL around foo.  This caused
a "make check" test to fail.  With electric-pair-mode enabled and
electric-pair-skip-whitespace set to 'chomp, in the following:

    "  (
       )  "

, typing ) on line 1 should replace the ) on line 2, "chomping" the space
between ) and ).  However the string-fence property on L1's NL prevented
electric-pair-mode from functioning correctly.  João and I have discussed
at length ways of fixing this.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Also, the CC Mode solution has the disadvantage that other languages
cannot get the same fontification advantages, namely that the "foo gets
warning-face on the ", and string face extends ONLY to EOL.

What I'm now proposing, and implementing as a trial, is to enhance the
syntax table facilities to support unterminated strings.  There will be
an extra syntax flag `s' on newlines meaning "terminate any open string".
This is straightforward for forward scanning, but somewhat complicated
for backward scanning.  However, it does enable unterminated strings to
be easily fontified to EOL in any language, with minimal effort.

It should allow the desired fontification without causing problems for
electric-pair-mode.

Stefan is concerned that the extra functionality may not justify the
increase in complexity in syntax.c.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).