There's some discussion about terminal identification and
there's what looks to be some consensus for adopting these
two environment variables that were pioneered by Apple.
refs: https://github.com/mintty/mintty/issues/881
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
We need to gate with the config generation check as update_title
can be called during the configuration reloading process and
the tab bar state may not reflect the config until after the
config is reloaded!
refs: https://github.com/wez/wezterm/issues/173
Teach the window layer about window icons and implement the
plumbing for this on X11.
For Wayland there is no direct way to specify the icon; instead
the application ID is used to locate an appropriate .desktop filename.
We set the app id from the classname but that didn't match the installed
name for our desktop file which is namespaced under my domain, so change
the window class to match that and enable the window icon on Wayland.
refs: https://github.com/wez/wezterm/issues/172#issuecomment-619938047
This was a bit of a pain to track down because this behavior
isn't specified anywhere or called out explicitly.
The issue is that if you use a true color escape sequence such as
```bash
printf "\x1b[38;2;255;100;0mTRUECOLOR\n"
```
the active color would remain active when switching between the
primary and the alt screen until something (eg: `ls --color`) changed
it again.
I hadn't run into this because in my prompt, many many years ago, I had
it set to perform an SGR reset (`\x1b[0m`) as the first thing to ensure
that the shell is in a saner state.
For users that don't do this they end up with a weird looking color
bleed effect.
refs: https://github.com/wez/wezterm/issues/169
On windows, prevent console subsystem processes spawned by
lua (such as the `wsl -l` example configuration) from momentarily
popping up and stealing the focus. This was happening too fast
to see in most cases, but could cause the wezterm window to momentarily
repaint its title bar with lose focus before regaining it.
This fixes an annoyance with the configuration error window;
previously we would spawn a new window for each error that
was discovered in the config, which cluttered up the screen
and felt irritating when iterating on the config file.
This commit reuses the connection status UI infra to make a
single persistent error log window.
This commit adds some helper functions that make it possible to
dynamically discover and add WSL distributions to the launcher
menu.
refs: https://github.com/wez/wezterm/issues/159
* ctrl-R to find a line and then hit enter would cause the search
text rather than the match text to be returned and run!
* When exiting the editor, clear to end of screen to make sure
that we clean up any UI from the incremental search status
This helps us keep track of the extent and cursor position that
we render for the line editor, making it easier to make the editor
rendering more fancy.
This restructures the LineEditor to allow the hosting application to
override key presses and apply custom edits to the editor buffer.
Methods for performing predefined actions and for accessing the line
buffer and cursor position have been provided/exposed to support this.
One consequence of this change is that the editor instance needs to be
passed through to the host trait impl and that means that the LineEditor
can no longer be generic over `Terminal`. Instead we now take `&mut dyn
Terminal` which was how the majority of non-example code was using it in
any case. This simplifies a bit of boilerplate in wezterm but adds an
extra line to the most basic examples.
On Windows, if you run `wsl.exe` from the terminal and start zsh
(maybe bash also?) and it enables application cursor key mode,
exiting zsh doesn't clear application cursor key mode and when we
return to the shell and are using virtual terminal input rather
than the native windows console input, we'll continue to receive
application cursor key sequences instead of regular cursor key
input sequences.
This commit recognizes both flavors as arrow movement
in the line editor to make this feel less broken.
Without this, `wzsh` will keep the terminal in raw mode between
line editor invocations, resulting in staggered/stairway output
for any spawned commands.
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
With the revised native windows console renderer using the various
console APIs more deeply, I've seen a couple of cases where those
API calls fail inside eg: wezterm running via the new pty machinery.
Using the virtual terminal APIs and the terminfo renderer is the
right thing to do in that case.
This commit probes for virtual terminal support and uses the builtin
xterm terminfo, unless the environment has
`TERMWIZ_BYPASS_VIRTUAL_TERMINAL=1` set. This allows forcing the
use of the windows console layer.
