syntax mode parsing could improve just a little

[fbrau]

Hi. I've been reading syntax mode code and it seems very clever to avoid full parsing
but I've encountered several times with cases when multiline tokens where:

considering the code:
char* hello = "hello \ world \ godbye"; int x = 1;

and having
world \ goodbye"; int x = 1;
on focus, the syntax mode 'world goodbye' are displayed in normal text and
'"; int x = 1...' is displayed a string token.

The "parser" doesnt recognize "world \ godbye" comes from a string
opening just a few lines before the focused text. I've searching a few points in the
code and there is actually a function in dmsyntax.c (setup(...)) which implements some
king of backtraking to detect this case. Managed to understand it somehow but
it is never evaluated.

I want to implement a buffer option to effect in the parsing code to
"alternate" the syntax detection considering the first token is part of
a multilinetoken (coment or string), nothing smart, just an option.

I modified the setup(...) function to do just that by this is not in the path
of syntax drawing.

Where this feature should go in the code or where begins the parsing?

[mbert]

I'm afraid, I don't know either. Surely Steve (the original author) knows, but he has not contributed any code for several years.

[fbrau]

Hi, I've been reading the code a bit more... And it is too much heuristics in the author's head
it should require a complete rewrite to make it more general (the syntax parser is hard fixed
to C style at several pints)

Anyways I got a solution for my needs.

See, this python code (the window) begins with a huge multiline comment, then comes a few
python statements followed by a huge multiline string.

Default elvis syntax parsing produces this (incorrect and confusing):

If i set the altmultiline option (my patch):

This makes the initial syntax parser setup to make the backwards multiline recognition
simpler (the default is much more clever [and gives C style precedence]) and just assume the text shown actually continues a multiline token (string or comment)

I've been using this when I have code like this (huge multlines) and It at least gives more
pleasant syntax coloring on this cases. Once I'm done with this section of my code I get
back to default syntax parsing with "set noaltmultiline".

The patch

It additionaly adds a new "show" argument: "set show=...,altmultiline" to know if I'm using
this alternative mode or not.