* Adds `CopyTo` and `PasteFrom` assignments that specify the
destination/source.
* Adds `default_clipboard_copy_destination` and `default_paste_source`
config options that specify the default destination/source for
existing `Copy` and `Paste` operations (for @bew)
* Deprecating `PastePrimarySelection` in favor of `PasteFrom`.
* Added `CTRL-Insert` -> `Copy` (for @Babar)
Aside from the new key assignment, these changes shouldn't change
the default behavior, but do make it easier to consider changing
that in a later commit.
They should allow for example:
* Set `default_clipboard_copy_destination = "PrimarySelection"` to
prevent populating the clipboard by default when using the mouse.
* Overriding the CTRL-Insert, CTRL-SHIFT-C to explicitly populate
the clipboard
* Set `default_paste_source = "PrimarySelection"` for middle click
to paste the selection.
* Overriding SHIFT-Insert, CTRL-SHIFT-V to explicitly paste from
the clipboard.
refs: #417
* Add config option to specify default current working directory
* Make `cwd` of CLI take precedence over `default_cwd`
* Update docs for `default_cwd` and Launching Programs
Explains the `default_cwd` property more succinctly on the `Config` struct.
Adds documentation on the various ways to set the working directory and the logic used to decide the working directory.
* Add ClearBuffer action
Clears all lines, both visible and those scrolled off the top of the viewport, making the prompt line the new first line and resetting the scrollbar thumb to the full height of the window.
This is the behavior that Hyper / xterm has for clearing the terminal.
* Combine ClearBuffer into ClearScrollback as enum with associated erase mode
Makes it easier to manage the different options of clearing the terminal.
The default is true, which means that adjusting the font size will
cause the window to resize to preserve the number of rows/cols in
the terminal.
When set to false, the window size is preserved and the number of
terminal rows/cols is adjusted instead.
refs: https://github.com/wez/wezterm/issues/431
I started this a while ago; it's pretty time consuming to produce
accessible and usable documentation for this sort of stuff, so
this isn't yet complete, but in the interest of avoiding additional
bit-rot, let's get this up.
refs: https://github.com/wez/wezterm/issues/257
The heart of this issue was that the resize callbacks have two
layers of state; one in the low level window and one in the application
level window.
On Windows, the system triggers the low level callback prior to
opengl being initialized. Since the application level depends on
the opengl state, there are some code paths where it NOPs and
returns early if opengl isn't yet initialized.
When the system-wide display scaling is set to say 200%, the application
layer can't know the effective DPI of the window it is creating because
it doesn't know which monitor will be used or what its DPI will be.
New windows are created at the default DPI of 96, and we rely on the
resize events to detect the actual DPI and adjust the scaling in
the window.
The early call of the resize callback meant that the low level and
application level size/dpi state was out of sync and the result was
that the window had half as many pixels as it should, but that the
terminal model was still sized as though it had the correct amount
(twice as many as visible). This resulted in the window being too
small for the viewport.
The resolution is simple: we now suppress emitting the resize processing
until opengl has been initialized.
The test scenario for this is:
* Set system scaling to 100%
* Launch wezterm
* Set system scaling to 200%
* Observe that wezterm scales to match
* Press CTRL-SHIFT-N to spawn a new window
* Observe that the new window size matches the other window (previously
this one would be half the size)
While I was looking at this, I noticed that the manifest didn't
match the DPI awareness that we have in the code, so update that.
refs: https://github.com/wez/wezterm/issues/427
This appears to have been broken since the introduction of mouse
assignments :-/
This commit adds Pane::is_alt_screen_active so that the gui layer
can tell whether the alt screen is active, and allow passing down
the event.
refs: #429
This persuades the CI to install both the arm and intel flavors
of the rust toolchain on macOS, and the deploy script to generate
a universal binary.
* need big sur to build for M1
* Use cross-compilation compatible mlua from my fork for now
I've seen a number of people copy and paste the example that runs
`top` and be confused by it, so try to make it a bit clearer how
to get a regular split with a shell inside it.
If a font doesn't have any latin glyphs then we'd compute 0 as the
average width. Later, during rendering, we'd compute an `inf` scaling
factor and then subsequently fail to allocate texture space.
This commit takes the average width from a "random" selection of glyphs
(whatever the first few glyphs in the font may be) to avoid that
situation.
refs: https://github.com/wez/wezterm/issues/404
I didn't recreate precisely the situation in the issue, but I
tried pressing both `AltGr 8` and `CTRL ALT 8` with a DEU
layout active and both now result in `[` being emitted.
refs: #392
80214319ae broke the use of RUST_LOG to
turn up trace logging.
This commit refactors logger initialization into the env-bootstrap crate
so that it is centralized, and adopts the use of `WEZTERM_LOG` to
override the default logging filters, rather than `RUST_LOG`.
The default is 1.0. `line_height` is used to scale the effective
cell height, increasing the amount of space between font baselines.
refs: https://github.com/wez/wezterm/discussions/387
