Option to override environment variables in child processes #5063
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today I have to restart Kakoune in order to set environment variables
in shell expansions globally. For example KAK_LSP_FORCE_PROJECT_ROOT or RUST_BACKTRACE.
Another use case is when using
rust-analyzer
's test framework.When a test fails, it tells me to run
env UPDATE_EXPECT=1 cargo test
to update test with the actual behavior.The
kakoune-cargo
plugin does not provide a way to set environment variables.The reason I want to run this from the editor is that this allows me to run only the test at cursor (using
rust-analyzer
code lenses).When running ":git" commands, there is an ambiguity on whether to
use the $PWD or the buffer's worktree. We use $PWD but it should be
possible to override this behavior. An obvious way to do this is to
override Git environment variables:
(another in-flight patch adds the obvious default to GIT_DIR so we don't need to set that).
There are some minor issues left
intuitive. Since neither environment variables nor ui_options ever
need a = in the key name, we can get rid of the escaping.
Alternative approach: The str-to-str-map can be somewhat clunky. We
could instead export any option named like env_FOO. Not yet sure
which approach is better.
Alternative: maybe a
setenv
orexport
command?Closes #4482
That issues asks for a separate client-specific env as well but we
don't have a client scope so I'm not sure.