When installed by the installer, we add registry entries to configure
directory context entries in explorer.exe that enable "Open WezTerm
here" to function.
This works by running your default program with the current working
directory set to the one specified.
I plan to only enable this when installed by the installer so that
these can be deleted/updated by the installer later on.
If you want wezterm to run a different program by default, then
you can change the default_prog config in the wezterm configuration;
I don't plan on adding lot of context menu entries for this.
Note that attempting to open in the `C:\` root doesn't always seem
to work for me. I haven't had a chance to understand what's going
on there.
refs: https://github.com/wez/wezterm/issues/155
I've been meaning to do this for a while: the intended purpose
is to use this to filter ansi escape sequences out of the prompt
in the shell pre-command hook.
tweak some container names
fixup container names and regenerate the config
Ensure that curl is installed
the rust toolchain stuff wants curl
run apt update before apt install
centralize updating apt, and install sudo
revise get-deps script for slimmer debian images
more container related tweaks
get-deps: Don't require lsb-release on debianish systems
more get-deps improvements
Explicitly ask GH actions to recursively checkout the repo
Explicitly install git
fetch tags and tweak git build for debian systems
moar adjustments
remove deb8 (its wayland is too old), fixup debian publish
Ensure git build deps are installed always, tidy up sudo usage
This commit allows loading the console functions from `conpty.dll`
instead of `kernel32.dll` which means that we can update and
track newer features than have been deployed to Windows.
In practical terms this means that we can now unlock mouse input
reporting in eg: VIM running under WSL.
refs: https://github.com/microsoft/terminal/issues/376
We're jumping the gun on this issue, which is tracking making
a proper supportable way to deploy this sort of update:
refs: https://github.com/microsoft/terminal/issues/1130
For now it seems easier just for us to bundle our own copy of
these bits.
This includes a speculative change to include those in our
Windows downloads also.
The binaries were built from
4f8acb4b9f
* take a stab at fixing the windows CI to generate 64-bit
* use actions-rs/toolchain more broadly
* fixup target dir for deploy script
* cut over to the rust action for installing rust
Sometimes we race with the nightly build while it is deleting
and uploading artifacts.
Since they have stable names, just hard code those in the the
markdown.
* harfbuzz includes some ttf fixtures.
* libpng has some test images
* the wezterm web page has some movie files(!)
None of these are required to be in the source tarball, so strip them
out to save ~40MB and bring the tarball down to <5MB.
Refs: https://github.com/wez/wezterm/issues/46
It takes ~30 minutes to schedule a release build that takes just
over 50 minutes to run. Travis kills builds that take 50 minutes,
so this is completely useless.
Meanwhile: azure is able to build and deploy all platforms within
the first 15-20 minutes.
Streamline the travis deploy builds; when TRAVIS_TAG is set
we'll run `--release` builds.
Don't error out in fontconfig/build.rs if fontconfig is not
installed. This makes it possible to `cargo test --all` again
on the mac at the cost of potentially making it harder to troubleshoot
problems with not having fontconfig installed on linux.
However: the get-deps script is responsible for installing that.
This is primarily for macos where the default freetype
installation is unable to render color emoji, but should also
help make things more consistent across the various platforms.
It's a little bit awkward on linux because the font-loader crate
pulls in the now-conflicting servo-font* crates. I've disabled
font-loader on linux systems; it's just calling fontconfig under
the covers anyway.
I've had mixed results with esctest; the IRM and cursor save/restore
tests fail for me in terminal.app, iterm2 and xterm, and fail in the
same way on wezterm, so I'm not sure if I'm not running those tests
correctly. However, they did encourage the discovery of some other
real issues in the wezterm emulation.
