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

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.