ctrl+shift+p filters: :st2 :st3 :win :osx :linux
Browse

Nix

by wmertens ALL

Nix syntax highlighting for Sublime Text

Details

Installs

  • Total 4K
  • Win 353
  • Mac 1K
  • Linux 2K
May 19 May 18 May 17 May 16 May 15 May 14 May 13 May 12 May 11 May 10 May 9 May 8 May 7 May 6 May 5 May 4 May 3 May 2 May 1 Apr 30 Apr 29 Apr 28 Apr 27 Apr 26 Apr 25 Apr 24 Apr 23 Apr 22 Apr 21 Apr 20 Apr 19 Apr 18 Apr 17 Apr 16 Apr 15 Apr 14 Apr 13 Apr 12 Apr 11 Apr 10 Apr 9 Apr 8 Apr 7 Apr 6 Apr 5 Apr 4
Windows 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 3 1 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0
Mac 0 0 0 1 1 2 1 1 0 0 2 1 1 0 0 0 0 2 0 1 4 0 0 1 2 1 0 0 1 2 2 0 2 2 2 0 2 1 0 1 2 2 0 0 1 3
Linux 1 1 1 5 5 2 3 4 3 2 4 3 2 6 3 2 4 4 2 3 3 5 1 0 0 0 4 2 3 1 0 2 0 1 4 4 3 2 2 0 0 4 16 1 1 1

Readme

Source
raw.​githubusercontent.​com

sublime-nix

Nix syntax highlighting for Sublime Text.

This syntax tries to be complete, and marks illegal code as such.

Unfortunately, the syntax highlighter in Sublime Text does not implement a full state machine and therefore this is an approximation of the actual syntax Nix allows. It's a bit looser and will mark things as illegal in corner cases.

Specifically, it has to guess whether { starts an attribute set or a function call, and it can't look ahead to the next lines, so it allows both until it's sure. However, this means that on column 0 the expression end-condition can match on a , or } and this breaks the syntax highlighting. As soon as it is sure of one or the other, this no longer applies. So this is only applicable to empty {} and comma-first function calls on column 0, not a big problem.

Tested against the nixpkgs code and the Nix test suite, it seems to render those ok.

There is some fun code in here, approximating a proper parser by recursing into rules with end conditions matching end of expression.