1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-25 14:22:37 +03:00
wezterm/config/Cargo.toml

45 lines
1.2 KiB
TOML
Raw Normal View History

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
[dev-dependencies]
pretty_env_logger = "0.4"
2020-10-02 21:50:50 +03:00
[dependencies]
anyhow = "1.0"
battery = "0.7"
introduce freetype_load_flags and freetype_load_target config In the earlier times wezterm supported different font rasterizers, and the configuration was a bit vague and generic to accomodate differences in how the rasterizers worked. Since then, we've standardized on freetype. One of the things that's been bothering me for a while is that we have some fiddly logic to transform from the config to the freetype flags. This commit does away with the transformation and simply exposes the two sets of freetype options. The main thing that I expect people to play with is `freetype_load_target` which can have one of the following values: ``` pub enum FreeTypeLoadTarget { /// This corresponds to the default hinting algorithm, optimized for standard gray-level rendering. Normal, /// A lighter hinting algorithm for non-monochrome modes. Many generated glyphs are more fuzzy but better resemble its original shape. A bit like rendering on Mac OS X. This target implies FT_LOAD_FORCE_AUTOHINT. Light, /// Strong hinting algorithm that should only be used for monochrome output. The result is probably unpleasant if the glyph is rendered in non-monochrome modes. Mono, /// A variant of Normal optimized for horizontally decimated LCD displays. HorizontalLcd, /// A variant of Normal optimized for vertically decimated LCD displays. VerticalLcd, } ``` I expect most people will want to set this to one of `Normal`, `Light` or `HorizontalLcd`. `HorizontalLcd` is what `font_antialias=Subpixel` used to select. refs: #491
2021-02-21 00:54:56 +03:00
bitflags = "1.0"
bstr = "0.2"
chrono = {version="0.4", features=["unstable-locales"]}
dirs-next = "2.0"
enum-display-derive = "0.1"
filenamegen = "0.2"
hostname = "0.3"
2020-10-02 21:50:50 +03:00
lazy_static = "1.4"
2020-10-03 06:51:50 +03:00
libc = "0.2"
2020-10-02 21:50:50 +03:00
log = "0.4"
luahelper = { path = "../luahelper" }
2021-01-13 21:06:35 +03:00
mlua = {version="0.5", features=["vendored", "lua54", "async", "send"]}
2020-10-02 21:50:50 +03:00
# file change notification
notify = "4.0"
portable-pty = { path = "../pty", features = ["serde_support"]}
promise = { path = "../promise" }
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"
smol = "1.2"
terminfo = "0.7"
2020-10-02 21:50:50 +03:00
termwiz = { path = "../termwiz" }
2020-10-05 10:06:01 +03:00
toml = "0.5"
umask = { path = "../umask" }
unicode-segmentation = "1.7"
wezterm-input-types = { path = "../wezterm-input-types" }
2020-10-02 21:50:50 +03:00
wezterm-term = { path = "../term", features=["use_serde"] }
2020-10-05 21:57:08 +03:00
[target."cfg(windows)".dependencies]
winapi = { version = "0.3", features = ["winuser"]}