nushell/features.toml

[hintsv1]

description = "Adding hints based upon error states in the syntax highlighter"
enabled = false

[coloring_in_tokens]

description = "Move coloring into the TokensIterator so they can be atomic with the rest of the iterator"
reason = """
This is laying the groundwork for merging coloring and parsing. It also makes token_nodes.atomic() naturally
work with coloring, which is pretty useful on its own.
"""
enabled = false
Feature flagging infrastructure This commit adds the ability to work on features behind a feature flag that won't be included in normal builds of nu. These features are not exposed as Cargo features, as they reflect incomplete features that are not yet stable. To create a feature, add it to `features.toml`: ```toml [hintsv1] description = "Adding hints based on error states in the highlighter" enabled = false ``` Each feature in `features.toml` becomes a feature flag accessible to `cfg`: ```rs println!("hintsv1 is enabled"); ``` By default, features are enabled based on the value of the `enabled` field. You can also enable a feature from the command line via the `NUSHELL_ENABLE_FLAGS` environment variable: ```sh $ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run ``` You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`. This commit also updates the CI setup to run the build with all flags off and with all flags on. It also extracts the linting test into its own parallelizable test, which means it doesn't need to run together with every other test anymore. When working on a feature, you should also add tests behind the same flag. A commit is mergable if all tests pass with and without the flag, allowing incomplete commits to land on master as long as the incomplete code builds and passes tests. 2019-10-11 20:39:05 +02:00			`[hintsv1]`

			`description = "Adding hints based upon error states in the syntax highlighter"`
			`enabled = false`
Start moving coloring into the token stream The benefit of this is that coloring can be made atomic alongside token stream forwarding. I put the feature behind a flag so I can continue to iterate on it without possibly regressing existing functionality. It's a lot of places where the flags have to go, but I expect it to be a short-lived flag, and the flags are fully contained in the parser. 2019-10-15 01:11:00 +02:00
			`[coloring_in_tokens]`

			`description = "Move coloring into the TokensIterator so they can be atomic with the rest of the iterator"`
			`reason = """`
			`This is laying the groundwork for merging coloring and parsing. It also makes token_nodes.atomic() naturally`
			`work with coloring, which is pretty useful on its own.`
			`"""`
			`enabled = false`