Improved Swift support for Highlight.js

svanimpe · 2021-03-03T17:17:07.340Z

Hi everyone,

I'm happy to report that versions 10.6 and 10.5 of highlight.js include significant improvements to its Swift rendering. These improvements concern keywords, built-ins, operators, attributes, implicit parameters, property wrappers, raw strings, string interpolation, generic parameters and arguments, operator declarations, and precedence groups.

I've also added a large test suite, but more tests are welcome, as are improvements to the themes.

Enjoy!

Note that I am not a maintainer of HLJS, only a user/contributer. HLJS was the easiest highlighting option for me to integrate into my writing/publishing setup. However, its Swift support was quite basic and I encountered many issues with it, so I ended up rewriting and expanding it. Because what better way to spend your holiday break than to write regular expressions in JavaScript

xAlien95 · 2021-03-08T09:58:05.565Z

Thank you for contributing!

I wonder why highlighters aren't using TextMate Language Grammars since they are pretty much a "standard" nowadays (they are used in Atom and VS Code and their parsing algorithm is probably 100% written in JavaScript too). It would reduce a lot maintaining costs.

As a side note, do we know which highlighter is used in these forums? Its highlighting algorithm is pretty much broken, since c is for some reason highlighted differently:

let a = 1
let b = 2
let c = 3

Edit: it's HLJS

svanimpe · 2021-03-08T11:51:57.354Z

xAlien95:

I wonder why highlighters aren't using TextMate Language Grammars since they are pretty much a "standard" nowadays

Because the TextMate grammar is massive (MBs not KBs) and too large to be acceptable for client-side rendering. The HLJS grammar will never offer the same detailed highlighting as TextMate, because its size has to be constrained.

xAlien95:

As a side note, do we know which highlighter is used in these forums? Its highlighting algorithm is pretty much broken, since c is for some reason highlighted differently:

Yes, c was listed as a built-in for some reason. Maybe there once was a Standard Library function with that name?
This is one of the issues I fixed, so when this forum updates to a newer version of HLJs, that issue should be resolved.

Dante-Broggi · 2021-03-08T15:51:27.277Z

The highlighting for c is because of @convention(c), IIRC.

svanimpe · 2021-03-08T18:16:17.231Z

Ah, that makes sense

The new grammar for attributes also handles these arguments, so the c will still be highlighted:

github.com

highlightjs/highlight.js/blob/db295672afe8f49a659aad66db470bb0ff74b840/src/languages/lib/kws_swift.js#L275


      
          // Valid identifier.
          export const identifier = concat(identifierHead, identifierCharacter, '*');
          
          
// Valid type identifier.
          export const typeIdentifier = concat(/[A-Z]/, identifierCharacter, '*');
          
          
// Built-in attributes, which are highlighted as keywords.
          // @available is handled separately.
          export const keywordAttributes = [
            'autoclosure',
            concat(/convention\(/, either('swift', 'block', 'c'), /\)/),
            'discardableResult',
            'dynamicCallable',
            'dynamicMemberLookup',
            'escaping',
            'frozen',
            'GKInspectable',
            'IBAction',
            'IBDesignable',
            'IBInspectable',
            'IBOutlet',

Nevin · 2021-03-08T18:27:27.762Z

Speaking for myself, when reading and writing posts on these forums, I would much prefer that “c” should never be highlighted in code blocks.

If someone writes @convention(c) I want the “c” a normal color, and if someone writes let c = 2 I definitely want the “c” a normal color.

I never want to see “c” any color other than normal.