wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-25 14:22:37 +03:00
Code Issues Projects Releases Wiki Activity
523660c192
wezterm/wezterm-gui/Cargo.toml

131 lines
3.8 KiB
TOML
Raw Normal View History

split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[package]
name = "wezterm-gui"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
build = "build.rs"
Raise minimum Rust version to 1.51, de-vendor openssl on unix Rust 1.51 allows addressesing a long-standing TODO which was that we shouldn't need to build a vendored copy of openssl on most sensible unix systems. We do require a vendored copy on macOS and Windows, but due to the way that Cargo's feature resolver worked, it wasn't possible for this requirement to be respected. Rust 1.51 introduces `resolver="2"` which can deal with this feature resolution! https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2 The upshot of this is that building wezterm on real unix systems that are not macos will now link against the system libssl, resulting in both a shorter compile time and less headaches arising from having a slightly different openssl used by wezterm than the rest of the system. cc: @jsgf
2021-03-25 19:34:00 +03:00
resolver = "2"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
Allow building without wayland support You can run `cargo build --release --no-default-features` to build without wayland support. This is useful for systems that do not have wayland (eg: the `slint` distro).
2021-06-27 03:05:22 +03:00
[features]
Add compile time features to allow building without vendored fonts closes: #2305
2022-09-09 18:40:05 +03:00
default = ["vendored-fonts", "wayland"]
Allow building without wayland support You can run `cargo build --release --no-default-features` to build without wayland support. This is useful for systems that do not have wayland (eg: the `slint` distro).
2021-06-27 03:05:22 +03:00
wayland = ["window/wayland"]
add distro-defaults feature The intent is that when set, it changes defaults to something more suitable for distributions. I've also added a readme for distro maintainers. refs: https://github.com/wez/wezterm/issues/1795
2022-07-11 02:34:43 +03:00
distro-defaults = ["config/distro-defaults"]
Add compile time features to allow building without vendored fonts closes: #2305
2022-09-09 18:40:05 +03:00
vendor-nerd-font-symbols-font = ["wezterm-font/vendor-nerd-font-symbols"]
vendor-jetbrains-font = ["wezterm-font/vendor-jetbrains"]
vendor-roboto-font = ["wezterm-font/vendor-roboto"]
vendor-noto-emoji-font = ["wezterm-font/vendor-noto-emoji"]
vendored-fonts = [
"vendor-nerd-font-symbols-font",
"vendor-jetbrains-font",
"vendor-roboto-font",
"vendor-noto-emoji-font"
]
Add support for heap profiling using dhat refs: https://github.com/wez/wezterm/issues/2626
2022-11-14 23:26:02 +03:00
dhat-heap = ["dhat"] # if you are doing heap profiling
dhat-ad-hoc = ["dhat"] # if you are doing ad hoc profiling
Allow building without wayland support You can run `cargo build --release --no-default-features` to build without wayland support. This is useful for systems that do not have wayland (eg: the `slint` distro).
2021-06-27 03:05:22 +03:00
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[build-dependencies]
anyhow = "1.0"
[target.'cfg(windows)'.build-dependencies]
build(deps): bump embed-resource from 1.7.2 to 1.7.3 Bumps [embed-resource](https://github.com/nabijaczleweli/rust-embed-resource) from 1.7.2 to 1.7.3. - [Release notes](https://github.com/nabijaczleweli/rust-embed-resource/releases) - [Commits](https://github.com/nabijaczleweli/rust-embed-resource/compare/v1.7.2...v1.7.3) --- updated-dependencies: - dependency-name: embed-resource dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
2022-07-04 04:27:21 +03:00
embed-resource = "1.7"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
cc = "1.0"
[dependencies]
anyhow = "1.0"
deps: update bitflags -> 1.3
2021-08-16 04:21:17 +03:00
bitflags = "1.3"
Basic useless wgpu based rendering foundation
2022-11-16 04:19:48 +03:00
bytemuck = { version="1.4", features=["derive"]}
remove transitive dep on time 0.1 chrono still is pulling this in for some reason. Super frustrating. refs: https://github.com/chronotope/chrono/issues/602
2023-04-18 23:50:42 +03:00
chrono = {version="0.4", default-features=false}
deps: update to clap 4 Deal with some breaking changes
2022-10-04 18:51:01 +03:00
clap = {version="4.0", features=["derive"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
codec = { path = "../codec" }
deps: update Main thing to note here is that the open crate has deprecated open::that_in_background, but made open::that non-blocking. I think this is OK, but I'm a little cagey about what will happen with this on Windows. We may need to spawn our own thread for this if things go awry.
2022-06-13 06:17:48 +03:00
colorgrad = "0.6"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
config = { path = "../config" }
downcast-rs = "1.0"
Add support for heap profiling using dhat refs: https://github.com/wez/wezterm/issues/2626
2022-11-14 23:26:02 +03:00
dhat = {version="0.3", optional=true}
term: allow iterm2 file transfer protocol Adds some plumbing to allow the GUI to implement a download handler and connect that up for iterm2 image/file transfers that have their inline property set to false. Previously we'd just log an error. Now we will by default download the file to the user's download directory. This behavior can be turned off via the new `allow_download_protocols` configuration setting. File transfers can be initiated on a remote host via the https://iterm2.com/utilities/it2dl script. When the download completes, a toast notification is shown that will open the file when clicked. refs: https://github.com/wez/wezterm/discussions/1450
2021-12-22 19:17:29 +03:00
dirs-next = "2.0"
cargo update
2023-05-01 18:36:25 +03:00
emojis = "0.6"
wezterm: fixup APPIMAGE environment consistently Need to apply the same logic in wezterm-gui as we do in the wezterm-cli.
2020-10-25 09:21:03 +03:00
env-bootstrap = { path = "../env-bootstrap" }
deps: upgrade euclid -> 0.22
2020-12-10 21:03:16 +03:00
euclid = "0.22"
deps: fastrand -> 2.0
2023-06-19 20:44:21 +03:00
fastrand = "2.0"
filedescriptor: remove anyhow from public interface Use thiserror instead
2021-05-24 00:24:01 +03:00
filedescriptor = { version="0.8", path = "../filedescriptor" }
deps: upgrade finl_unicode to 1.2
2022-10-23 22:07:00 +03:00
finl_unicode = "1.2"
char selector: track recently selected emoji and use frecency to show it refs: https://github.com/wez/wezterm/issues/2163
2022-09-01 08:56:58 +03:00
frecency = { path = "../frecency" }
add wezterm.mux lua module The intent is to expose Mux related functions to lua, so `wezterm.mux` will be that module table. In order to test this out in the debug overlay, I realized that the overlay was running functions in a different thread and didn't have access to the mux, so this commit also tweaks the debug overlay repl to execute the input in the main thread. The result is that it is now possible to do `wezterm.mux.active_workspace()` in the debug overlay to print the active workspace name. More functions will follow. refs: https://github.com/wez/wezterm/issues/225
2022-06-17 17:46:25 +03:00
futures = "0.3"
launcher now has fuzzy matching Just start typing text to build up the fuzzy matching term. The list of items updates to match the results. refs: #664 refs: #1485
2022-01-04 18:45:15 +03:00
fuzzy-matcher = "0.3"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
hdrhistogram = "7.1"
deps: http_req -> 0.9
2023-02-05 17:38:55 +03:00
http_req = "0.9"
improve handling of animated webp images Use mainline image crate to avoid an otherwise unavoidable panic in the upstream: https://github.com/image-rs/image/issues/1775 Explicitly operate on the frames from the animation. refs: https://github.com/wez/wezterm/issues/3250
2023-03-15 21:34:47 +03:00
# we want image 0.24.6 or later. see https://github.com/wez/wezterm/issues/3250
image = {version="0.24", git="https://github.com/image-rs/image.git", rev="fe069785ae245a2c510fd724ef96da283b05a236"}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
lazy_static = "1.4"
libc = "0.2"
refactor: move lfucache into its own crate
2022-11-14 06:20:15 +03:00
lfucache = { path = "../lfucache" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
log = "0.4"
luahelper = { path = "../luahelper" }
deps: cargo update, and a couple of dependabot suggestions
2021-07-19 05:10:46 +03:00
metrics = { version="0.17", features=["std"]}
cargo update
2022-08-21 18:51:16 +03:00
mlua = {version="0.8.3", features=["send"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
mux = { path = "../mux" }
lua: add window:mux_window() and pane:mux_window() methods These allow converting the gui versions of these objects to the mux versions. refs: https://github.com/wez/wezterm/issues/225
2022-06-28 06:28:26 +03:00
mux-lua = { path = "../lua-api-crates/mux" }
use blob leases for decoded animation frames This allows the decoder thread to live only long enough to decode the full set of frames; we can then store the leases in memory and pull them in only when there is a cache miss. refs: https://github.com/wez/wezterm/issues/3263
2023-03-19 07:52:53 +03:00
once_cell = "1.8"
deps: ordered-float closes: https://github.com/wez/wezterm/pull/1946
2022-05-02 07:43:22 +03:00
ordered-float = "3.0"
mux: Pane is now required to be Send+Sync. Use Arc<dyn Pane>
2022-11-23 19:05:30 +03:00
parking_lot = "0.12"
pty: try_clone_writer -> take_writer This breaking API change allows us to explicitly generate EOF when the taken writer is dropped. The examples have been updated to show how to manage read, write and waiting without deadlock for both linux and windows. Need to confirm that this is still good on macOS, but my confidence is high. I've also removed ssh2 support from this crate as part of this change. We haven't used it directly in wezterm in a long while and removing it from here means that there is slightly less code to keep compiling over and over. refs: https://github.com/wez/wezterm/discussions/2392 refs: https://github.com/wez/wezterm/issues/1396
2022-08-12 17:38:18 +03:00
portable-pty = { path = "../pty", features = ["serde_support"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
promise = { path = "../promise" }
deps: update pulldown_cmark, cargo update
2021-12-27 19:49:22 +03:00
pulldown-cmark = "0.9"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
rangeset = { path = "../rangeset" }
ratelim= { path = "../ratelim" }
regex = "1"
serde = {version="1.0", features = ["rc", "derive"]}
serde_json = "1.0"
macos: use interactive shell for .command scripts This is primarily so that the user's environment is set up prior to invoking the script. refs: #2871
2022-12-20 18:30:07 +03:00
shlex = "1.1"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
smol = "1.2"
tabout = { path = "../tabout" }
Image decoding is now done in a bg thread Continuing from the previous commit, this shifts: * In-memory data -> temporary file * Image decoding -> background thread The background thread asynchronously decodes frames and sends them to the render thread via a bounded channel. While decoding frames, it writes them, uncompressed, to a scratch file so that when the animation loops, it is a very cheap operation to rewind and pull that data from the file, without having to burn CPU to re-decode the data from the start. Memory usage is bounded to 4 uncompressed frames while decoding, then 3 uncompressed frames (triple buffered) while looping over the rest. However, disk usage is N uncompressed frames. refs: https://github.com/wez/wezterm/issues/3263
2023-03-17 21:11:46 +03:00
tempfile = "3.4"
update terminfo to 0.8
2023-03-24 20:12:49 +03:00
terminfo = "0.8"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
termwiz = { path = "../termwiz" }
config: split out lua functions into their own crates This shaves off some build time and allows more parallism in the build.
2022-05-19 08:49:53 +03:00
termwiz-funcs = { path = "../lua-api-crates/termwiz-funcs" }
deps: textwrap -> 0.16 closes: https://github.com/wez/wezterm/pull/2664
2022-10-24 06:50:47 +03:00
textwrap = "0.16"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
thiserror = "1.0"
deps: tiny-skia -> 0.11
2023-07-10 04:28:48 +03:00
tiny-skia = "0.11"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
umask = { path = "../umask" }
unicode-normalization = "0.1"
deps: update unicode-segmentation to 1.8
2021-08-12 07:56:30 +03:00
unicode-segmentation = "1.8"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
unicode-width = "0.1"
url = "2"
walkdir = "2"
wezterm: add experimental_bidi config option and very basic bidi This commit is larger than it appears to due fanout from threading through bidi parameters. The main changes are: * When clustering cells, add an additional phase to resolve embedding levels and further sub-divide a cluster based on the resolved bidi runs; this is where we get the direction for a run and this needs to be passed through to the shaper. * When doing bidi, the forced cluster boundary hack that we use to de-ligature when cursoring through text needs to be disabled, otherwise the cursor appears to push/rotate the text in that cluster when moving through it! We'll need to find a different way to handle shading the cursor that eliminates the original cursor/ligature/black issue. * In the shaper, the logic for coalescing unresolved runs for font fallback assumed LTR and needed to be adjusted to cluster RTL. That meant also computing a little index of codepoint lengths. * Added `experimental_bidi` boolean option that defaults to false. When enabled, it activates the bidi processing phase in clustering with a strong hint that the paragraph is LTR. This implementation is incomplete and/or wrong for a number of cases: * The config option should probably allow specifying the paragraph direction hint to use by default. * https://terminal-wg.pages.freedesktop.org/bidi/recommendation/paragraphs.html recommends that bidi be applied to logical lines, not physical lines (or really: ranges within physical lines) that we're doing at the moment * The paragraph direction hint should be overridden by cell attributes and other escapes; see 85a6b178cfddee94b3ddb39c26652bbd5a973666 and probably others. However, as of this commit, if you `experimental_bidi=true` then ``` echo This is RTL -> عربي فارسی bidi ``` (that text was sourced from: https://github.com/microsoft/terminal/issues/538#issuecomment-677017322) then wezterm will display the text in the same order as the text renders in Chrome for that github comment. ``` ; ./target/debug/wezterm --config experimental_bidi=false ls-fonts --text "عربي فارسی ->" LeftToRight 0 ع \u{639} x_adv=8 glyph=300 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=244 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 6 ي \u{64a} x_adv=4 glyph=363 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 9 ف \u{641} x_adv=11 glyph=328 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=240 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=278 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 17 ی \u{6cc} x_adv=4 glyph=664 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 19 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 20 - \u{2d} x_adv=8 glyph=276 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 21 > \u{3e} x_adv=8 glyph=338 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ``` ``` ; ./target/debug/wezterm --config experimental_bidi=true ls-fonts --text "عربي فارسی ->" RightToLeft 17 ی \u{6cc} x_adv=9 glyph=906 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=277 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=4.78125 glyph=272 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=241 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 9 ف \u{641} x_adv=5 glyph=329 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 6 ي \u{64a} x_adv=9 glyph=904 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=243 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=5 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 0 ع \u{639} x_adv=6 glyph=301 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText LeftToRight 0 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 1 - \u{2d} x_adv=8 glyph=480 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 2 > \u{3e} x_adv=8 glyph=470 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ; ``` refs: https://github.com/wez/wezterm/issues/784
2022-01-25 18:16:51 +03:00
wezterm-bidi = { path = "../bidi" }
ImageDataType::File -> EncodedLease Adopt the new blob lease layer to storing and referencing image files. This reduces the number of open files needed when images are being displayed in the terminal. refs: https://github.com/wez/wezterm/issues/3263
2023-03-19 06:32:49 +03:00
wezterm-blob-leases = { path = "../wezterm-blob-leases", version="0.1", features=["simple_tempdir"] }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
wezterm-client = { path = "../wezterm-client" }
config: cut over to wezterm-dynamic Avoid using serde for mapping between Lua and Rust for the `Config` struct. This improves the build speed of the config crate by 2x; it goes down from 30 seconds to 9 seconds on my 5950x.
2022-05-14 18:00:03 +03:00
wezterm-dynamic = { path = "../wezterm-dynamic" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
wezterm-font = { path = "../wezterm-font" }
wezterm-gui-subcommands = { path = "../wezterm-gui-subcommands" }
wezterm-gui: we now start an implicit unix mux server When running the GUI, we generate a unix domain socket path for the current process and start up a mux server for that path. This allows `wezterm cli list` and `wezterm cli split-pane` to work implicitly inside the GUI session. When started in this way, the mux server is not persistent; when the GUI process is terminated, all of its windows, tabs and panes are terminated. refs: https://github.com/wez/wezterm/issues/230
2020-12-30 02:58:39 +03:00
wezterm-mux-server-impl = { path = "../wezterm-mux-server-impl" }
add own open_url crate The upstream open crate keeps making stuff async/blocking/not-working on windows, so this is a step towards removing this dependency. refs: https://github.com/wez/wezterm/issues/3288
2023-03-19 22:44:12 +03:00
wezterm-open-url = { path = "../wezterm-open-url" }
RemoteSshDomain now uses wezterm-ssh crate There are a few notable changes as a result: * A number of `.ssh/config` options are now respected; host matching and aliasing and identity file are the main things * The authentication prompt is inline in the window, rather than popping up a separate authentication window Refs: https://github.com/wez/wezterm/issues/457
2021-03-28 03:49:30 +03:00
wezterm-ssh = { path = "../wezterm-ssh" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
wezterm-term = { path = "../term", features=["use_serde"] }
tweak updating checking * Allow injecting some initial output to new panes * Have the update checker set this new-pane-banner to a short upsell to let the user know there is an update. * Refactor toast notifications into their own crate * Have the update checker call a new stub function that triggers a toast notification with an URL... but it does nothing because the rust ecosystem doesn't support this on macos yet and I'm writing this code there
2020-12-13 11:17:10 +03:00
wezterm-toast-notification = { path = "../wezterm-toast-notification" }
deps: upgrade wgpu 0.15 -> 0.16
2023-04-20 07:48:13 +03:00
wgpu = "0.16"
window: wayland support is no longer optional at build time
2021-05-09 01:20:23 +03:00
window = { path = "../window" }
lua: add wezterm.window.screens() Currently implemented on X11 only, this function returns information about the geometry of the screen(s). This is taken from the same source of information we use for the `--position` CLI argument to `wezterm start`. ``` > wezterm.window.screens() { "by_name": { "DisplayPort-1": { "height": 2160, "name": "DisplayPort-1", "width": 3840, "x": 0, "y": 0, }, }, "main": { "height": 2160, "name": "DisplayPort-1", "width": 3840, "x": 0, "y": 0, }, "origin_x": 0, "origin_y": 0, "virtual_height": 2160, "virtual_width": 3840, } ```
2022-07-06 18:32:13 +03:00
window-funcs = { path = "../lua-api-crates/window-funcs" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[target."cfg(windows)".dependencies]
shared_library = "0.1"
deps: update
2021-12-20 18:15:56 +03:00
uds_windows = "1.0"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
winapi = { version = "0.3", features = [
"winuser",
"consoleapi",
"handleapi",
"fileapi",
"namedpipeapi",
"synchapi",
"winsock2",
]}
Use newer windows crate
2022-03-07 03:01:59 +03:00
windows = { version="0.33.0", features = [
"Win32_UI_Shell",
]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
Add shaper post-processing function This function is intended to deal with certain kinds of ligatures and certain combining sequences that don't have corresponding glyphs. It isn't hooked up to the gui yet, but does have unit tests that are probably mostly correct. refs: https://github.com/wez/wezterm/issues/478
2021-02-22 20:19:05 +03:00
[dev-dependencies]
update k9 to 0.11.0 to make it work with rustc@1.51.0 1.51.0 no longer takes non string literals in `panic()`. k9@0.11.0 fixes that
2021-03-25 20:32:31 +03:00
k9 = "0.11.0"
env_logger -> 0.10 closes: https://github.com/wez/wezterm/pull/2803
2022-11-28 07:37:25 +03:00
env_logger = "0.10"
benchmarking shaping `cargo test --release -p wezterm-gui -- --nocapture bench_shaping`: ``` running 1 test 100: 139.82µs 1000: 385.333µs 10000: 3.144203ms test shapecache::test::bench_shaping ... ok ```
2021-04-28 07:48:15 +03:00
benchmarking = "0.4"
Reference in New Issue Copy Permalink