bathos/Ecmascript-Sublime

A few more issues

Closed this issue · 3 comments

You said that you're not gonna fix my previous report because "it is not a real code". Which criterium do you use to distinguish between "real" and "imaginary" code?

However, I tried to find better issues which you probably want to fix (like one with if statement etc).

// Function name after comment
function/**/*a(){};

// Assignment target after comment
[a,]/**/=a;

// Function name on a new line
function
*a(){};

// Arrow function after comment
(...a)/**/=>a

What is real code if this is not? People sometimes put comment to describe function name, so the first one may appear in real code. Same for second one. The third one is actually spotted in older version of jsNetworkX.min.js which means that this definitelly appear in real situations. Fourth one, like first one, may appear if someone want to add comment just before arrow in an arrow function. The second example doesn't mark code as error, but instead doesn't highlight comma in assignment array correctly (like it does if you remove the comment).

I have a lot of new issues, so please tell me are these ones acceptable for what you want to fix? If yes, I would be glad to post all issusues I found so far of this type.

There are no objective criteria I can provide. But to give an example from the last batch, one was failure to recognize spreading a numeric literal. While lexically and semantically valid, in practice this would imply an augmented Number.prototype having a Symbol.iterator implementation (doing god knows what). Though technically calling this "not real code" is a subjective determination, I think it’s very self-evident that [....2] is a contrived case that nobody would seriously write unless trying to craft code puzzles.

In the ideal case, I’d love for it to be precise enough to manage such cases, but we’re pretty constrained by practical concerns and limitations associated with regex-based matching and the inability to look across line breaks. Anything that requires token lookaheads can end up being somewhat fragile in such a highlighting system esp. in a syntax def like this that attempts more specific matches than is typical. All of the examples here fall in that category.

So, for the case of () /**/=> {} for example, in order to disambiguate the () as parameters, we need to know about the => that follows. We could expand the regex lookahead to account for one or more multiline comment, but it would increase the cost of the match and would only work if the multiline comments were actually not multiline.

Likewise for placing a comment between function and * and ] and =. These are all cases where we cannot entirely match correctly if there is a linebreak in the same position that you have placed a (single line) multiline comment.

If you can furnish some examples of code that places comments in places like (...a)/**/=>a I’d consider expanding the regex to account for it, but (a) it will still never work if there is a linebreak (like in example 3 above) and (b) for each such oddball case we attempt to cover, the cost of highlighting increases.

@bathos Then you should at least change the description of your project which currently says "Sublime-syntax definition for ES6+ with absurdly specific scopes". There are hundreds of syntax highlighters which cover a lot more cases than your package. Your description should be titled "Basic JavaScript syntax definitions for ES1".

If your goal was to create a pretty good and fast JavaScript highlighter which covers absurdly many cases, then you obviously missed your goal. Apparently you said that the problem is sublime's syntax highlighting concept, which is based on regex and is very slow and doesn't allow a lot of lookahead. Then, why even use sublime? (a) Sublime is not free, while there are thousands of faster and better syntax highlighters which are free and open source (b) See again (a).

Your idea to create absurdly precise and fast JavaScript syntax highlighter sounds great to me. Why then using the most silliest software you could found like sublime? Why not create your own free and open source syntax highlighter which would be able to do much better and much faster highlighting than sublime?

Wow, so many great questions. I’ll give this some thought, thanks.