helix-syntax mostly existed for the sake of the build task which
checks and compiles the submodules. Since we won't be relying on
that process anymore, it doesn't end up making much sense to have
a very thin crate just for some functions that we could port to
helix-core.
The remaining build-related code is moved to helix-term which will
be able to provide grammar builds through the --build-grammars CLI
flag.
The unwrap (or '.ok()' rather) triggers for some errors but not
negative status codes. In the case where helix is being packaged
in an empty git repository, the existing mechanism will fail because
git init
git rev-parse HEAD
gives a negative exit code and prints to stderr
stderr: "fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree....
with a stdout of "HEAD\n" (too short to slice with [..8]).
If building from source and the source is contained in a larger
repository, we'd contain the wrong version. It's also easy to
accidentally have a newer tag that would change the version.
* Add commit hash to version info, if present
* Rename GIT_HASH to indicate that it includes version, fix linter error
* Add whitespace after use statement
Co-authored-by: Ivan Tham <pickfire@riseup.net>
Co-authored-by: Ivan Tham <pickfire@riseup.net>