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

Nix

by wmertens ALL

Nix syntax highlighting for Sublime Text

Details

Installs

  • Total 5K
  • Win 527
  • Mac 2K
  • Linux 3K
Oct 29 Oct 28 Oct 27 Oct 26 Oct 25 Oct 24 Oct 23 Oct 22 Oct 21 Oct 20 Oct 19 Oct 18 Oct 17 Oct 16 Oct 15 Oct 14 Oct 13 Oct 12 Oct 11 Oct 10 Oct 9 Oct 8 Oct 7 Oct 6 Oct 5 Oct 4 Oct 3 Oct 2 Oct 1 Sep 30 Sep 29 Sep 28 Sep 27 Sep 26 Sep 25 Sep 24 Sep 23 Sep 22 Sep 21 Sep 20 Sep 19 Sep 18 Sep 17 Sep 16 Sep 15 Sep 14
Windows 0 0 1 0 0 0 0 2 1 0 0 0 0 3 0 1 0 0 1 0 0 2 0 0 0 0 0 2 1 3 1 0 1 0 1 0 0 0 0 1 0 0 0 0 0 1
Mac 0 0 1 1 0 0 0 0 0 1 0 1 1 1 1 0 0 0 1 1 0 0 0 6 0 0 1 0 2 1 0 0 0 2 2 0 2 3 1 2 2 1 0 0 0 0
Linux 0 2 0 1 1 2 1 3 5 1 3 1 1 0 1 1 1 1 2 1 1 4 0 0 2 1 4 3 1 1 1 0 2 1 0 2 3 3 0 4 2 1 2 0 2 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.