Unknown pseudo class is tokenized wrong

[dummdidumm]

Please select any editor that you're experiencing this issue in.

• Visual Studio Code
• Sublime Text 2/3
• TextMate 2

Please provide the name/repo of the color scheme package you're using:

• irrelevant

(optional) Please include any packages/extensions you're using which could be conflicting:

• Deferring to the VS Code less syntax highlighting from within a Svelte file's style tag

---

When using an unknown pseudo class, the highlighting ends up in a broken state, which can influence/mess up how the code after it is highlighted.

Example:

:global(.demo) {
    color: blue;
}

Will provide just meta.selector.less as the token for :global, but it should be entity.other.attribute-name.pseudo-class.less like it is for known pseudo classes, like is:(.demo) { }.

This came up in sveltejs/language-tools#2650, the repo for the Svelte extension which defers the syntax highlighting of <style lang="less"> to VS Code's built-in grammar, which to my knowledge is this grammar. :global is not a spec-ed pseudo class, rather a Svelte-specific one.

As far as I can see this is due to https://github.com/radium-v/Better-Less/blob/master/Syntaxes/Better%20Less.YAML-tmLanguage#L1952 only matching on a known list of pseudo classes.

[radium-v]

Hi @dummdidumm,

I'd rather avoid adding a blanket :pseudo()-style rule, since CSS and Less don't support arbitrary pseudo selectors. Would it make more sense to add custom rules to svelte-vscode to handle these Svelte-specific cases?

I'm not super familiar with Svelte but it looks like :global and :global() are the only two cases that would need to be accounted for. I'll take a look and see if I can get a PR up for you.

[blake-regalia]

hey @radium-v - i'm the one who originally opened the issue in sveltejs.

Any chance you might reconsider adding a final "catch-all"/blanket pseudo style rule? I think it would actually make sense for this lexer regardless of svelte. For example, current highlighting breaks when it encounters an unfinished pseudo-selector name with args.

While typing :where, notice how the the text that follows is mis-tokened:

Once a selector is matched:

I wouldn't be convinced if someone tried to tell me that this "is a feature, not a bug" ;) and I would think that adding a catch-all at the right place would help prevent breaking the lex not only for LESS/CSS, but for all languages that embed it and rely on matching some exit pattern that never happens if this package is "stealing" all the tokens.

[radium-v]

Good news - after being stubborn all evening, I found two ways forward.

There actually is a matcher for "other possible pseudo-elements", which currently captures vendor-prefixed pseudo elements. Making the prefix part of the regex an optional group will allow :global to be recognized. For :global() to work, I may have to adjust how the namespace accessors are handled. The current behavior is indeed a bug, and I'll have a PR up for the fix soon.

Alternatively, the following snippet could be added to svelte.tmlanguage.src.yaml, which would specifically define the :global() and :global pseudo-selectors for Less in svelte:

  'L:meta.style.svelte meta.lang.less - L:meta.property-list':
    patterns:
    - name: entity.other.attribute-name.pseudo-class.less
      begin: (:)(global)(?=\()
      beginCaptures:
        '1': {name: punctuation.definition.entity.less}
      end: \)
      endCaptures:
        '0': {name: punctuation.definition.group.end.less}
      patterns:
      - begin: \(
        beginCaptures:
          '0': {name: punctuation.definition.group.begin.less}
        end: (?=\))
        patterns:
        - include: 'source.css.less#selectors'
    - name: meta.function-call.less
      match: (:)(global)\b
      captures:
        '1': {name: punctuation.definition.entity.less}
        '2': {name: entity.other.attribute-name.pseudo-class.less}

[blake-regalia]

There actually is a matcher for "other possible pseudo-elements", [...] Making the prefix part of the regex an optional group will allow :global to be recognized.

That's great! I was looking in the same place actually. The only potential issue I noticed was that it could interfere with LESS' :extend(), which I believe could be solved by reordering these two lines: https://github.com/radium-v/Better-Less/blob/master/Syntaxes/Better%20Less.YAML-tmLanguage#L2442-L2443

[dummdidumm]

Thank you very much for looking into this! Since it sounds like you have a plan to fix both of these I'll just wait for now - this is nothing urgent for me personally.