Re: scratch/fontify-open-string. [Was: CC Mode and electric-pair "problem".]

[Alan Mackenzie <acm@muc.de>]

Hello, Stephen.

Many thanks for trying out and testing this branch.

I'm afraid I've found a rather large snag - there are backward moving
commands and functions in Emacs which bypass proper syntax checking.
For example, in the following in (the modified) shell-script-mode:

1.    foo="Foo"
2.    bar="Bar
3.

, with point at BOL3, a C-M-b moves to the F, rather than "Bar.

This is because (forward-comment -1) crashes into the "whitespace" at
the end of L2 (the newline) rather than taking account of its syntax
(the string closing flag).

At the very least, the function back_comment (in src/syntax.c) will need
to be modified to take account of such things, and in doing so, might as
well become a function that also goes back over EOL-terminated strings,
as Stefan suggested.  This will be a lot of work.

I fear there may be several, or even many, lisp functions in Emacs which
may likewise need modifying.

The root cause of this problem, in the abstract, is that Emacs attempts
to scan backwards over strings and comments, which is only heuristically
possible, rather than scanning forwards over the same constructs and
remembering the endpoints.

Right at the moment, I don't know how to proceed.  Sorry.

-- 
Alan Mackenzie (Nuremberg, Germany).


On Sun, Jul 15, 2018 at 04:00:23 -0500, Stephen Leake wrote:
> An update on this; I just had several missing quotes in a buffer, due to
> a copy/multiple paste that had a quote error. I did lots of editing with
> the quote errors present.

> I didn't even notice them until the compiler complained, just like any
> other syntax error.

> In my opinion, that is far preferable to the previous behavior of
> fontifying large parts of the buffer as string, which forced me to pay
> attention to a trivial syntax error instead of what I was actually doing.

> This is in Ada, that does not have the option of escaping a newline to
> create a multiline string, so treating a newline as string terminator is
> always correct.

> Anything I can do to help merge this to main?

> Stephen Leake <stephen_leake@stephe-leake.org> writes:

> > Alan Mackenzie <acm@muc.de> writes:
> >
> >> It's no longer a matter of assumption.  Earlier on this afternoon, I
> >> committed a preliminary working version of this change to the branch
> >> scratch/fontify-open-string.
> >
> > I've just tried this in ada-mode, and it works nicely. I like the red
> > face on an unbalanced string quote.
> >
> > No noticeable slowdown in anything I've tried so far.
> >
> > Let me know if there's some experiment you'd like me to run.

> -- 
> -- Stephe