I've kept resizing in there because it doesn't appear to render
a border in mutter and seems useful.
I think I'll probably change WindowDecorations to bitflags so
that the user can control this, but first need to verify what
windows supports for this.
mouse move events in the tab bar, and paint events, could cause
the title bar state to be recomputed.
Make sure that we don't trigger the status event to trigger for those.
refs: https://github.com/wez/wezterm/issues/500
I've only tested this on macos, but it should be cross platform,
with the caveat that Wayland doesn't let a window position itself,
so this won't work there.
We were using the value that was active when the window was created,
and never updating it.
This commit sweeps the interval check into the existing periodic
window maintenance routine.
refs: https://github.com/wez/wezterm/issues/500
The API isn't finalized; this is proof of concept for putting something
in the area to the right of the new tab button.
The info will be right aligned to the tab area.
```lua
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
-- demonstrates shelling out to get some external status.
-- wezterm will parse escape sequences output by the
-- child process and include them in the status area, too.
local success, date, stderr = wezterm.run_child_process({"date"})
-- Make it italic and underlined
window:set_right_status(wezterm.format({
{Attribute={Underline="Single"}},
{Attribute={Italic=true}},
{Text="Hello "..date},
}));
end)
return {
}
```
refs: https://github.com/wez/wezterm/issues/500
As explained in the docs included in this commit, ideally this
wouldn't be needed, but due to a long-standing hinting bug in
freetype <https://gitlab.freedesktop.org/freetype/freetype/-/issues/761>
it seems most expedient to just render our own block glyphs,
so that's what this does!
refs: #433
This commit expands on the prior commits to introduce the concept
of per-window configuration overrides.
Each TermWindow maintains json compatible object value holding
a map of config key -> config value overrides.
When the window notices that the config has changed, the config
file is loaded, the CLI overrides (if any) are applied, and then
finally the per-window overrides, before attempting to coerce
the resultant lua value into a Config object.
This mechanism has some important constraints:
* Only data can be assigned to the overrides. Closures or special
lua userdata object handles are not permitted. This is because
the lifetime of those objects is tied to the lua context in which
they were parsed, which doesn't really exist in the context of
the window.
* Only simple keys are supported for the per-window overrides.
That means that trying to override a very specific field of
a deeply structured value (eg: something like `font_rules[1].italic = false`
isn't able to be expressed in this scheme. Instead, you would
need to assign the entire `font_rules` key. I don't anticipate
this being a common desire at this time; if more advance manipulations
are required, then I have some thoughts on an event where arbitrary
lua modifications can be applied.
The implementation details are fairly straight-forward, but in testing
the two examplary use cases I noticed that some hangovers from
supporting overrides for a couple of font related options meant that the
window-specific config wasn't being honored. I've removed the code that
handled those overrides in favor of the newer more general CLI option
override support, and threaded the config through to the font code.
closes: #469closes: #329
`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: https://github.com/wez/wezterm/issues/469
refs: https://github.com/wez/wezterm/issues/499
This is defined as a trait method on Pane (default: false), and has the
obvious transitive equivalent methods in Tab and Window (eg: if all
contained items are `can_close_without_prompting`, then that container
is also `can_close_without_prompting`).
The intent is to avoid bothering the user to confirm closing a window
when the content is not stateful and doesn't warrant it.
For example: the window that is displayed in the event of a
configuration error really shouldn't prompt to the user to confirm
closing it.
All termwiztermtab panes are `can_close_without_prompting==true`
to effect this policy.
In the future, we could teach LocalPane to lookup the session leader
process against a list of "uninteresting" or "stateless" processes
and return an appropriate result (as suggested in
https://github.com/wez/wezterm/issues/280). That functionality
is NOT part of this commit.
