8 Commits (274f2ea45979098a96b7a6d94ecc18351826eaea)

Author	SHA1	Message	Date
yvt	6d16d2cbc9	feat: support grammar cross-compilation	2 years ago
Michael Davis	838cfcc7cd	publish a source tarball with version and grammars (#1875) ... * publish a source tarball with version and grammars * include_str! the release version from a VERSION file * remove setting of .version file from tag don't need this anymore since the file is checked into source	3 years ago
Michael Davis	b157c5a8a4	fetch and compile tree-sitter grammars in helix-term build ... This restores much of the behavior that existed before this PR: helix will build the grammars when compiling. The difference is that now fetching is also done during the build phase and is done much more quickly - both shallow and in parallel.	3 years ago
Michael Davis	4fc991fdec	migrate grammar fetching/building code into helix-loader crate ... This is a rather large refactor that moves most of the code for loading, fetching, and building grammars into a new helix-loader module. This works well with the [[grammars]] syntax for languages.toml defined earlier: we only have to depend on the types for GrammarConfiguration in helix-loader and can leave all the [[language]] entries for helix-core.	3 years ago
Michael Davis	eeb3f8e963	migrate helix-syntax crate into helix-core and helix-term ... 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.	3 years ago
Michael Davis	a8cf0c6b90	filter git revision on git command success exit code (#1674) ... 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]).	3 years ago
Blaž Hrastnik	d3221b03a2	fix: Only parse git revision, don't use the tag for version ... 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.	3 years ago
Gygaxis Vainhardt	0949a0de7f	Add commit hash to version info, if present (#957) ... * 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>	3 years ago