wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-26 14:54:16 +03:00
Code Issues Projects Releases Wiki Activity
ba99c92cbd
wezterm/config/Cargo.toml

50 lines
1.4 KiB
TOML
Raw Normal View History

move config into its own crate
2020-10-02 21:50:50 +03:00
[package]
name = "config"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
build = "build.rs"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
add wezterm.on(), wezterm.emit() * `wezterm.on("event-name", func)` * `wezterm.emit("event-name", "arg1", "arg2")` `on` allows registering multiple functions. `emit` will call each of the registered functions in turn, passing a copy of the arguments. If a handler returns false, no additional handlers are called and `emit` will return false. Otherwise, once all the handlers have been called, `emit` will return true. `emit` is capable of being called by async code. These functions are available to the config layer, but nothing in wezterm uses them at this time. refs: #225
2020-10-07 08:04:48 +03:00
[dev-dependencies]
deps: remove pretty_env_loggger Go directly to the underlying env_logger crate, as pretty_env_logger hasn't been updated in some time, and I'd like to be able to redirect the log output to a file more directly, and that feature is in a newer version of the env logger than pretty_env_logger was pulling in.
2022-04-07 18:22:46 +03:00
env_logger = "0.9"
add wezterm.on(), wezterm.emit() * `wezterm.on("event-name", func)` * `wezterm.emit("event-name", "arg1", "arg2")` `on` allows registering multiple functions. `emit` will call each of the registered functions in turn, passing a copy of the arguments. If a handler returns false, no additional handlers are called and `emit` will return false. Otherwise, once all the handlers have been called, `emit` will return true. `emit` is capable of being called by async code. These functions are available to the config layer, but nothing in wezterm uses them at this time. refs: #225
2020-10-07 08:04:48 +03:00
move config into its own crate
2020-10-02 21:50:50 +03:00
[dependencies]
anyhow = "1.0"
lua: add `wezterm.battery_info()` function Queries the system battery information and returns an array of battery information. Each element is a lua table with the following entries: * state_of_charge: expressed as percents * vendor: the battery manufacturer * model: the battery model * serial: the battery serial number * time_to_full: how long until the battery is full * time_to_empty: how long until the battery is empty * state: "Charging", "Discharging", "Empty", "Full", "Unknown" I haven't run this on a system with a battery yet, so I'm holding off from showing an example until I've got a work one. refs: https://github.com/wez/wezterm/issues/500
2021-03-07 01:25:36 +03:00
battery = "0.7"
deps: update bitflags -> 1.3
2021-08-16 04:21:17 +03:00
bitflags = "1.3"
clean up mux server startup kindof a lot going on in this commit, unintentionally: * Need the lua context set to be moved into the config crate otherwise configs cannot be parsed by the server and we end up with the default configs * Make the server use smol for async io * Drop the use of the daemonize crate, which I had forked anyway. Just inline our own tighter daemonize module * Improve daemon spawning synchronization, however, it still needs work for windows to avoid blocking forever where we don't do daemonizing.
2020-10-04 19:39:28 +03:00
bstr = "0.2"
lua: add wezterm.strftime refs: https://github.com/wez/wezterm/issues/500
2021-03-02 20:51:56 +03:00
chrono = {version="0.4", features=["unstable-locales"]}
deps: colorgrad -> 0.5
2021-09-06 09:27:01 +03:00
colorgrad = "0.5"
deps: dirs -> dirs_next I saw that former is unmaintained, and dependabot wants to upgrade that one.
2020-12-10 21:08:49 +03:00
dirs-next = "2.0"
Allow matching font weight and font width in `wezterm.font` refs: https://github.com/wez/wezterm/issues/655
2021-04-09 01:41:07 +03:00
enum-display-derive = "0.1"
clean up mux server startup kindof a lot going on in this commit, unintentionally: * Need the lua context set to be moved into the config crate otherwise configs cannot be parsed by the server and we end up with the default configs * Make the server use smol for async io * Drop the use of the daemonize crate, which I had forked anyway. Just inline our own tighter daemonize module * Improve daemon spawning synchronization, however, it still needs work for windows to avoid blocking forever where we don't do daemonizing.
2020-10-04 19:39:28 +03:00
filenamegen = "0.2"
hostname = "0.3"
move config into its own crate
2020-10-02 21:50:50 +03:00
lazy_static = "1.4"
move running_under_wsl to config crate
2020-10-03 06:51:50 +03:00
libc = "0.2"
move config into its own crate
2020-10-02 21:50:50 +03:00
log = "0.4"
extract window::input to wezterm-input-types
2020-12-10 00:00:23 +03:00
luahelper = { path = "../luahelper" }
Add get_foreground_process_name, expose it and cwd in PaneInformation Add `get_foreground_process_name` to both Pane and the lua wrapper. Add `foreground_process_name` and `current_working_dir` fields to `PaneInformation`. In order for those to be dynamically fetched, switch the lua conversion for `PaneInformation` to be a UserData with field access methods. It's a little more verbose but allows us to lazily compute these two new fields. refs: https://github.com/wez/wezterm/discussions/1421 refs: https://github.com/wez/wezterm/issues/915 refs: https://github.com/wez/wezterm/issues/876
2021-12-24 04:44:12 +03:00
mlua = {version="0.7", features=["vendored", "lua54", "async", "send"]}
move config into its own crate
2020-10-02 21:50:50 +03:00
# file change notification
notify = "4.0"
quickselect: add QuickSelectArgs and helpers for opening urls This commit expands quick select mode so that you can trigger it with distinct sets of patterns (eg: urls on one key assignment, hashes on a different key assignment), different alphabets, and lastly, the option to perform a different action from the default copy action. You can pair this with `action_callback` to run lua code to do something with the selected text. This commit also adds `wezterm.open_with`, a helper function for opening documents/URLs. refs: #846 refs: #1362
2021-12-23 20:55:44 +03:00
open = "2.0"
FEATURE: Allow ScrollByPage f64 values `ScrollByPage` can accept non-integer values in the configuration. This allows fractional page scrolling, such as by half a page. The default remains the same, at 1 page.
2022-01-12 08:49:36 +03:00
ordered-float = { version = "2.10", features = ["serde"] }
move config into its own crate
2020-10-02 21:50:50 +03:00
portable-pty = { path = "../pty", features = ["serde_support"]}
extract window::input to wezterm-input-types
2020-12-10 00:00:23 +03:00
promise = { path = "../promise" }
move config into its own crate
2020-10-02 21:50:50 +03:00
serde = {version="1.0", features = ["rc", "derive"]}
add window:set_config_overrides lua method 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: #469 closes: #329
2021-02-28 01:53:19 +03:00
serde_json = "1.0"
wezterm.run_child_process is now async capable
2020-10-07 18:51:54 +03:00
smol = "1.2"
lua: add wezterm.format function The intent is to use this to compose text for a configurable tab bar. refs: https://github.com/wez/wezterm/issues/500
2021-03-02 11:15:37 +03:00
terminfo = "0.7"
allow setting selection colors with alpha values This commit allows the following configuration: ``` wezterm -n --config 'colors = { selection_fg = "clear", selection_bg = "rgba:50% 50% 50% 50%" }' ``` which sets the selection_bg to fully transparent, and selection_bg to 50% transparent gray. When selection_fg is fully transparent we'll use the normal fg color. When selection_bg is partially (or fully!) transparent, it will be alpha blended over the current cell background color. To support this, the config file will now accept rgba colors specified as 4 whitespace delimited numeric values. If a value ends with `%` it is interpreted as a number in the range 0-100. Otherwise, it is interpreted as a number in the range 0-255. The 4 values are red, green, blue, alpha. At this time, only the selection_fg and selection_bg settings accept alpha values. refs: #1615
2022-02-06 01:13:19 +03:00
termwiz = { path = "../termwiz", features=["use_serde"] }
upgrade misc deps, notably, async-task
2020-10-05 10:06:01 +03:00
toml = "0.5"
Take care to restore the original umask wezterm sets a more restrictive umask (`0o077`) by default so that any files that it creates (eg: unix domain socket, log files) are more secure by default. However, some environments rely on the more general default of (`0o022`) without checking that it is set. This matters because programs spawned by wezterm inherit its more restricted umask. I hadn't noticed this because I've had `umask 022` in my shell RC files since sometime in the 1990's. This commit adds some plumbing to the pty layer to specify an optional umask for the child process, and some more to our umask saver helper so that any thread can determine the saved umask without needing a reference to the saver itself, which may be in a different crate. The logic in the config crate has been adjusted to connect the saved value to the default command builder arguments. The net result of this is that running `wezterm -n start bash -- --norc` and typing `umask` in the resultant window now prints `0022`. refs: #416
2021-01-07 20:14:51 +03:00
umask = { path = "../umask" }
deps: update unicode-segmentation to 1.8
2021-08-12 07:56:30 +03:00
unicode-segmentation = "1.8"
bidi: tag Line with bidi mode This commit refines bidi property handling: * experimental_bidi has been split into two new configuration settings; `bidi_enabled` (which controls whether the terminal performs implicit bidi processing) and `bidi_direction` which specifies the base direction and whether auto detection is enabled. * The `Line` type can now store those bidi properties (they are actually split across 3 bits representing enabled, auto-detection and direction) * The terminal now has a concept of active bidi properties and default bidi properties * The default properties are pulled from the wezterm configuration * active bidi properties are potentially set via escape sequences, BDSM (which sets bidi_enabled) and SCP (which sets bidi_direction). We don't support the 2501 temporary dec private mode suggested by the BIDI recommendation doc at this time. * When creating new `Line`'s or clearing from the start of a `Line`, the effective bidi properties are computed (from the active props, falling back to default propr) and applied to the `Line`. * When rendering the line, we now look at its bidi properties instead of just the global config. The default bidi properties are `bidi_enabled: false` and `bidi_direction: LeftToRight` which corresponds to the typical bidi-unaware mode of most terminals. It is possible to live reload the config to change the effective defaults, but note that they apply, by design, to new lines being processed through the terminal. That means existing output is left unaffected by a config reload, but subsequently printed lines will respect it. Pressing CTRL-L or otherwise contriving to have the running application refresh its display should cause the refreshed display to update and apply the new bidi mode. refs: #784
2022-01-30 19:22:17 +03:00
wezterm-bidi = { path = "../bidi", features=["use_serde"] }
extract window::input to wezterm-input-types
2020-12-10 00:00:23 +03:00
wezterm-input-types = { path = "../wezterm-input-types" }
add wezterm.enumerate_ssh_hosts() helper This helper extracts the concrete set of hosts and their configurations from the ssh config, and arranges to reload the wezterm config if they are changed. This is useful when constructing ssh domain configs. refs: https://github.com/wez/wezterm/discussions/1731
2022-03-18 17:42:05 +03:00
wezterm-ssh = { path = "../wezterm-ssh" }
move config into its own crate
2020-10-02 21:50:50 +03:00
wezterm-term = { path = "../term", features=["use_serde"] }
maybe fixup build for windows
2020-10-05 21:57:08 +03:00
[target."cfg(windows)".dependencies]
winapi = { version = "0.3", features = ["winuser"]}
Reference in New Issue Copy Permalink