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

Nix

by wmertens ST2/ST3

Nix syntax highlighting for Sublime Text

Details

Installs

  • Total 1K
  • Win 91
  • OS X 378
  • Linux 551
Sep 17 Sep 16 Sep 15 Sep 14 Sep 13 Sep 12 Sep 11 Sep 10 Sep 9 Sep 8 Sep 7 Sep 6 Sep 5 Sep 4 Sep 3 Sep 2 Sep 1 Aug 31 Aug 30 Aug 29 Aug 28 Aug 27 Aug 26 Aug 25 Aug 24 Aug 23 Aug 22 Aug 21 Aug 20 Aug 19 Aug 18 Aug 17 Aug 16 Aug 15 Aug 14 Aug 13 Aug 12 Aug 11 Aug 10 Aug 9 Aug 8 Aug 7 Aug 6 Aug 5 Aug 4
Windows 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
OS X 0 0 0 0 0 1 0 0 0 1 1 2 0 0 0 2 0 0 3 1 0 0 0 0 0 1 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 1 1 0 0
Linux 0 0 0 0 1 0 2 1 1 0 0 1 0 1 1 0 1 0 0 0 0 0 1 1 0 0 0 2 0 0 0 1 1 0 1 1 1 0 1 0 0 1 1 0 0

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.