Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JavaScript lexer bugs & requests #1037

Open
1 task done
ct-martin opened this issue Jan 9, 2025 · 0 comments
Open
1 task done

JavaScript lexer bugs & requests #1037

ct-martin opened this issue Jan 9, 2025 · 0 comments
Labels

Comments

@ct-martin
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

Here's a hodgepodge of JavaScript lexer bugs & features. Apologies that I haven't done much with Go so I can't help with testing, but I'll try to include enough examples and/or regex changes for the XML to make this easier.

  • const & class are used for declarations but marked reserved

While MDN lists these as reserved keywords, it also lists let, var, function, etc. as reserved keywords. However, Chroma has the latter split out into KeywordDeclaration so it would make more sense to put const & class with let and var since they're used for a similar purpose.

  • as, from, & * should be keywords when used with import

Not sure how good of a way there is to do this in Chroma since this only applies when used with import, but...

import * as foo from "foo";
  • console builtin is missing

Strictly speaking, it's not technically a built-in to JS itself as a language, but it is a built-in on both browsers and Node, and would be useful to treat as such. I can also see NameBuiltinPseudo in a couple themes and I don't quite know what the difference between that and NameBuiltin are but it could be a better candidate for this.

console.log("Foo");
  • Names prefixes with class- or type-like keywords should be treated differently from a variable

For example:

class Foo {}

or:

new Foo();

or in TypeScript:

type Foo = {}
// along with the existing:
let x: Foo = {}

This won't catch all cases where they're used (and there isn't a good way to do that without analyzing every variable-like case), however, this would be an improvement even if it's just looking for preceding keywords.

  • Function names should be parsed as such rather than generic NameOther

For example:

function foo() {}
function bar () {} // with a space
const baz = () => {} // variable-like notation

This could be done adequately with the following regex lookahead:

(?=\s*(\=\s*)?\()

While not perfect, I was playing around in VS Code to see what syntax it would consider a variable vs function name and it seems to follow a similar logic. I didn't manage to track down their lexer so I don't know if there are any other edge cases, but this seemed to work comparably.

  • Missing a bunch of built-ins

A bunch of built-in type classes aren't on the list of builtins. While there's a lot of these and maybe not all are useful, there are common-enough ones like BigInt as well as some useful-in-odd-cases ones like Uint8ClampedArray (if you ever end up working with pixel data from the Canvas API).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects

To Reproduce

Chroma Playground

VS Code (ignore different colors on punctuation):

syntax highlighting screenshot


I'm not sure if you'd consider this as saving time or not since I'm not familiar with Go (and would be doing this a bit in the blind), but I can try writing a PR (just editing the XML) if you'd like.

(And also, thanks for the great tool; it's saved me a good bit of hassle)

@ct-martin ct-martin added the bug label Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant