zyedidia / flare Goto Github PK

Preprocessor statements could make grammars more readable and allow passing arguments when using/including a grammar.
My idea would be to have similar things to C. So id, define and makro.
They can also be used to customize the include of other grammars to eg. fix wrong highlighting.

For markdown this could look something like this:

block <- '```' (!"\n" .)* (!'```' .)* '```'?

# highlight code blocks if not disabled
$ifndef disable_code_highlighting

# disable code highlighting for markdown in code block
$define disable_code_highlighting

$makro BLOCK(LANG, CODE) CODE <- include{"LANG"} \
    CODEblock <- '```CODE' (!'```' (CODE / (. (!CODE .)*)))* '```'?

BLOCK(markdown, md)

code <- mdblock / block

$endif

code <- block

(This example is not that realistic)

They would also not really extend the syntax since the result of the preprocessor will be as before.

(This issue may be better at gpeg)

When adding a new language to the languages directory it is not possible to use it with the flare command without running go build again.

Edit: Ok, I have missed that changing languages always requires a rebuild...

When defining a theme most groups only need a foreground. It would be nice if properties that are not given are inherted from default or from the encasing group when highlighting.

If possible (I don't know if it is) it would be nice to implement the highlighting of incomplete code without making the .lang files more complicated.

Maybe that the end of the file matches anything instead of nothing.

A group maked as underlined is not shown as underlined.
I tested both html and print to terminal.

While most grammars will want the wrapper around the token it may be bad in some cases.
It would be nice if a grammar defines top it would be used instead of the default top.

In markdown for example headings can be at the start of the line.
This can be achived by splitting all lines (top <- (!\n line) \n?).
This would be possible with the token but it would be more of a hack and less efficient.

To solve the problem in markdown a character for start of the line and end of the line just like in regex would also be possible. I would say it would even say it would be the least hacky way. The problem is that it makes the code more complex and it would maybe require some backtracking.

Another note: When defining a custom top it would bypass the memo option. No idea how bad/good that is.