Re: cc-mode: Make all parameters introduced in Emacs 26 optional

[Alan Mackenzie]

Hello, Stefan.

On Sat, Mar 30, 2019 at 12:39:55 -0400, Stefan Monnier wrote:
> Hi Alan,

> > To set up a CC Mode derived mode to recognise strings 'like this', do the
> > following:
> > (i) Set the derived mode's value of `c-single-quotes-quote-strings' to t.
> > (This is done with `c-lang-defconst' in the derived mode's .el file).
> > (ii) Make sure the derived mode's value of
> > `c-get-state-before-change-function' does not include
> > `c-parse-quotes-before-change'.
> > (iii) Similarly ensure `c-before-font-lock-functions' doesn't contain
> > `c-parse-quotes-after-change'.
> > (iv) Ensure the derived mode's value of
> > `c-get-state-before-change-function' contains
> > `c-before-change-check-unbalanced-strings' and that of
> > `c-before-font-lock-functions' contains
> > 'c-after-change-mark-abnormal-strings'.
> > (v) Make sure `c-has-quoted-numbers' is nil.  (This is a pure C++
> > facility for writing numbers as 4'294'967'295.)
> > (vi) Ensure `c-multiline-string-start-char' (which allows strings to
> > continue over line ends without \) is set correctly for the mode.

> In non-CC modes, all it takes is

>     (modify-syntax-entry ?' "\"" st)
    
Maybe, but that doesn't give you the facilities that CC Mode offers,
namely that the delimiters of invalid constructs (such as unterminated
strings, or invalid character constants) get fontified with warning face.

> so is there somewhere in CC-mode's code where there's some comment or
> something that explains why this simple approach isn't sufficient?

There're comments which explain the strategems used to get the
font-lock-warning-face.

One question which has just occurred to me is why am I doing this in CC
Mode rather than the syntax and font-lock functionality handling it
directly?  Languages where strings don't extend over unescaped newlines
aren't exactly a rarity.

> I understand that things aren't always that simple:

> - you need to handle the 4'294'967'295 thingies in C++, but that should
>   only affect C++ and I'd assume that the C++ code handles it by
>   recognizing something like "[0-9]'" and changing the syntax-class of
>   those quotes so it shouldn't prevent multichar single-quoted strings.

More or less, although it checks there aren't two adjacent 's, and things
like that.

> - you apparently want to help the user catch the erroneous use of
>   single-quoted strings in those languages where single quotes are used
>   for chars rather than strings. but again this would seem to only
>   explain the need for c-single-quotes-quote-strings.

> But the above sounds surprisingly complex&scary,

It only looks like that because I've spelled it out so laboriously.  There
are two hook variables, each of which needs one function and the lack of
another.  There are two boolean constants which need setting.  It needs
to be done once when writing a mode, and only then when there's something
unusual, like 'strings like this'.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).