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.