Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a flag to keep a window open even though the child process has exited #499

Closed
sanga opened this issue Feb 24, 2021 · 4 comments
Closed

a flag to keep a window open even though the child process has exited #499

sanga opened this issue Feb 24, 2021 · 4 comments
Labels
enhancement New feature or request fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@sanga
Copy link

sanga commented Feb 24, 2021

Is your feature request related to a problem? Please describe.
Analogous to Alacritty's 'hold' flag (see: https://github.com/alacritty/alacritty/blob/34435ed776988e765d9327dcedfe909e440e6bf8/extra/completions/alacritty.fish#L32). My usecase for this is I have set up a link handler that may for example dump out some json to stdout from an api call. However when that command exits, the window closes before I had a chance to read the json. There are plenty of ways for me to work around this of course but none of them would be as convenient as adding such an option.

Describe the solution you'd like
To have such a flag.

Describe alternatives you've considered
There are definitely ways I could work around this, they are just a little bit clunky.

@sanga sanga added the enhancement New feature or request label Feb 24, 2021
wez added a commit that referenced this issue Feb 27, 2021
`exit_behavior = "Hold"` will keep the pane alive until explicitly
closed.  More details in the docs that are part of this commit.

refs: #499
@wez
Copy link
Owner

wez commented Feb 27, 2021

It's not quite what you asked for, but I just pushed a commit that enables a new exit_behavior option.

There isn't a way to override this via CLI options just yet; that's dependent on some plumbing described in the "bonus points" section of #469 (comment)

wez added a commit that referenced this issue Feb 27, 2021
`wezterm`, `wezterm-gui` and `wezterm-mux-server` now all support
a new `--config name=value` CLI option that can be specified
multiple times to supply config overrides.

Since there isn't a simple, direct way to update arbitrary fields
of a struct in Rust (there's no runtime reflection), we do this
work in lua.

The config file returns a config table. Before that is mapped
to the Rust Config type, we have a new phase that takes each
of the `--config` values and applies it to the config table.

For example, you can think of configuration as working like this
if wezterm is started as `wezterm --config foo="bar"`:

```lua
config = load_config_file();
config.foo = "bar";
return config;
```

The `--config name=value` option is split into `name` and `value`
parts.  The name part is literally concatenated with `config` in
the generated lua code, so the name MUST be valid in that context.
The `value` portion is literally inserted verbatim as the rvalue in the
assignment.  Not quoting or other processing is done, which means
that you can (and must!) use the same form that you would use in
the config file for the RHS.  Strings must be quoted.  This allows
you to use more complicated expressions on the right hand side,
such as:

```
wezterm --config 'font=wezterm.font("Fira Code")'
```

The overrides stick for the lifetime of the process; even if
you change the config file and reload, then the value specified
by the override will take precedence.

refs: #469
refs: #499
@wez
Copy link
Owner

wez commented Feb 27, 2021

With the latest commit on master you can now do: wezterm --config 'exit_behavior = "Hold"'

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Feb 27, 2021
@wez wez closed this as completed Feb 28, 2021
@sanga
Copy link
Author

sanga commented Feb 28, 2021

Looks perfect. Thanks Wez!

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

No branches or pull requests

2 participants