Improved syntax highlighting

[LittleBitwise]

Would it be possible to implement more specific rules for syntax highlighting? What would it take?

Currently I'm missing things like:

• local variables
• event/function parameters (and their use within event/function bodies)
• vector syntax (the surrounding angle brackets are currently considered operators)
• commas (general syntax, parameter separators, vector separators)
• parentheses and curly braces

(P.S. I'm using Makopo's Sublime Text package, in case that matters.)

[zaher]

This is just a database that used for editors and linters, you can post this feature request in https://github.com/Makopo/lslint

[LittleBitwise]

This is just a database that used for editors and linters, you can post this feature request in https://github.com/Makopo/lslint

Sorry for the mistake. The sublime syntax file has the following comment at the top:

# NOTE:   Following definitions are taken from kwdb (https://bitbucket.org/Sei_Lisa/kwdb).
#         Should you have any question about the avoid/event/function/constant
#         definitions, please check with the kwdb project and contact the kwdb
#         maintainer first. If kwdb have updated their database version and mine is
#         still old, please let me know.

The KWDB README mentions that it generates some kind of syntax highlighting related output for several things, so I assumed the source was here. 🙂

(I ended up hand-writing most of the syntax file from scratch overnight. It wasn't as bad as I thought.)

[zaher]

Why? What you wrote?

[zaher]

check this https://github.com/parmaja/miniedit/blob/master/bin/lsl.keywords

[LittleBitwise]

check this https://github.com/parmaja/miniedit/blob/master/bin/lsl.keywords

The syntax highlighter file for Sublime Text is just a bunch of regex in a YAML file. Makopo's repo has files which seemingly generate it programmatically. Instead of diving into the code, I tried just defining the syntax with regex which turned out to be relatively simple.

Besides basic syntax, I have function parameters and very good highlights for vectors. Most things are covered now, so my repo is public.

[zaher]

Dose it have autocomplete? Good we have now another editor to work with lsl we need vscode too

[Sei-Lisa]

In general, as Zaher said, it's not the purpose of this project to improve the few syntax highlighters that are provided; this only provides the keywords themselves and a few examples of how to apply them to existing highlighters, like GeSHi 1.0, also used for web highlighting in this LSL paste service: http://lsl.blacktulip-virtual.com/paste/ which is always up-to-date with the database because it's regenerated on every update.

But in addition to that, what LittleBitwise is asking goes beyond what most syntax highlighters are able to do. It requires to keep track of identifiers and language-specific syntax, therefore it needs to include the grammar of LSL. There are very few grammar-based highlighters; I have only heard about one for Emacs. Even then, I'm not sure if they go as far as keeping track of scopes and identifiers, but I doubt it, as scope management and symbol tables are not even part of the grammar itself; that's more what a compiler does. So, my understanding is that a grammar-based highlighter which includes the LSL grammar, would be able to highlight the commas in vectors differently to those in function parameters, but it wouldn't be able to track identifiers in order to highlight the different kinds distinctly; that would require a very LSL-specific highlighter with compiler capabilities.

tl;dr it's very unlikely to happen in any project, and out of scope of this project.

[Sei-Lisa]

Forgot to add that lslint is not by any means a syntax highlighter, it's actually a problem finder. Posting this feature request there would not be useful.

[zaher]

I want to ask a feature in lslint to generate json or any file format of for user functions and variables with positions

[LittleBitwise]

But in addition to that, what LittleBitwise is asking goes beyond what most syntax highlighters are able to do. It requires to keep track of identifiers and language-specific syntax, therefore it needs to include the grammar of LSL.

Just to clarify this part... As I created the syntax definition and an accompanying color scheme, I found out that Sublime Text has a built-in feature which essentially does this, in a very basic way using hashes of tokens based on the syntax. Ultimately it's something defined/enabled only by the color scheme, not the syntax as I originally understood.

That said, you're also correct about it not being possible to track which scope(s) a given token came from while defining the syntax, so it's not possible to differentiate between local variables and function parameters within the body of a function (or especially nested scopes).