Highlight Assets no Longer Required

[tajmone]

Since the Polygen definition for Highlight is now included in the official package (and has been so for a while, after this repository was created), we could safely remove the polygen.lang file from the repository.

• Delete polygen.lang
• Delete ebnf2.lang
• Update the READMEs accordingly.
• Remove Highlight definitions from .gitattributes

I still haven't set my mind on this, and will wait before taking any action — this Issue is here mainly as a reminder of this possibility.

NOTE — the Polygen syntax in the repository and the one shipped with Highlight are currently identical. The same goes for the ebnf2.lang definition, which is identical to the one in Highlight.

Considerations

There are pros and cons to this action:

Cons

If we ever need to update/improve the Polygen or EBNF definition, keeping it within the repository is a better option (and doesn't add any burdern).

Since the repository is set to download and use a specific version of Highlight, we don't need to worry about future updated of the app not being backward compatible.

Pros

On the other hand, if the Polygen or EBNF definition is updated mainstream (e.g. by a third party) it we would loose any benefits — integrating the new version would only require updating the download script that selects a specific release of Highlight.

Although I'm the creator and maintainer of both syntaxes, it's possible that someone will update one of those syntaxes in the future (more so the EBNF syntax) — which might bring benefits to us, but could also crack things up.

Conclusion

Either way, manually overriding the Polygen or EBNF syntax in the repository is a simple cut and paste operation, and keeping the definition local to the project allows ensuring that the exact Polygen definition is used, regardless of the Highlight release that end users adopt.

So it might be better right now to keep things as they are, and keep any eye on how Highlight evolves and if its syntaxes are updated (or, indeed, if the application undergoes changes that might require fixing the definitions).

[alvisespano]

I'm not sure my suggestion on this very topic could be of help, given your insight on this. Anyway I would keep things how they are.

[tajmone]

Anyway I would keep things how they are.

Me too. It's more of an "internal memo" for the future, and for the benefit of other maintainers (forks, etc.); but also something to keep an eye on, in case a future Highlight update might break our custom grammars (unlikely) and we might have to decide if we need to switch to the bundled ones (assuming they were re-adapted), and so on.

Whenever I can, I like to leave notes behind, because my memory is not always good, and I tend to spread thin over too many projects and then loose grip on where I left since my last updates.