Nothing generates them right now, and the mux client has no
way to represent them on the wire.
I'm considering constraining them to just win32 for now.
refs: https://github.com/wez/wezterm/issues/1509
It was showing the whole text for the cluster for each shaped
glyph.
Fix it up to map back to the corresponding cell range and
extract the text from the line.
Include the x_advance metric in the output while we're in
there.
refs: https://github.com/wez/wezterm/issues/1333
When rendering the IME composing text, I noticed that for the Korean
input sequence: shift+'ㅅ' followed by 'ㅏ' we'd render the 'ㅆ' (the
shifted first character) in black and the composing 'ㅏ' in white
against the cursor color, and that was very difficult to read,
especially at the default font size.
To resolve this, this commit:
* Forces clustering to break around the cursor boundary, so that
we treat the cursor position as its own separately styled cluster
* Adjusts cursor/bg rendering so that we always consider the start of
the cluster for the colors of that run. We are guaranteed that a
ligatured sequence will fit in the background area anyway.
This has the effect of "breaking" programming ligatures such as '->'
when cursoring through them, and decomposing them into their individual
'-' and '>' glyphs, which is a reasonable price to pay for being able
to see things better on screen.
refs: https://github.com/wez/wezterm/issues/1504
refs: https://github.com/wez/wezterm/issues/478
When we translate a dead key, send the composed event immediately
and don't try to route the current key press via the IME.
Improve rendering when in the composing state: overlay the composing
text at the cursor position to show what the composing text would
look like, even though it hasn't been committed to the input stream
yet.
refs: https://github.com/wez/wezterm/issues/1504
For Korean text input, pressing SHIFT and then typing in certain
keys begins a composition sequence. Our logic for when to route
via the IME got so distracted by ALT that it didn't consider SHIFT
and didn't send this sequence to the IME, so we'd fail to compose
those sequences.
While poking at this, I realized that we should treat this composition
similarly to dead keys, in that we can signal the term window to
highlight the cursor color and report that status.
There's some further work to do: the composing text should be rendered
by us. So far our IME integration assumes that the IME itself will
render over the top of our window, but for this particular input
it doesn't do that.
refs: https://github.com/wez/wezterm/issues/1504
The same core code is used to render both the tab navigator
and the launcher. The context is specified using some flags
so that you don't get an unholy mess in both places.
The net result of this is that the tab navigator now supports
fuzzy matching.
refs: #664
refs: 1485
* Allow selecting the first few rows by number
* Allow scrolling through long lists of items
* Add actions from key assignments to list
refs: #1485
refs: #1413
Since we now have RawKeyEvent and a sane way to indicate handling,
we don't need these any more, and it simplifies key dispatch to
remove them.
refs: #1483
Pass down whether we are in a live resize to the gui layer, so that
we don't incorrectly assume that the scale has changed, and fight
with the window manager.
Built this on my mac: will need to fixup for windows and linux.
refs: https://github.com/wez/wezterm/issues/1491
This commit adds a couple of helper methods that provide insight into
the state of the keyboard layer.
The intent is for users to add status information about the keyboard
state.
This commit also ensures that we schedule an update when the leader
key duration expires, and ensures that we close out the leader state
for an invalid key press.
refs: #686closes: #688
```lua
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
local leader = ""
if window:leader_is_active() then
leader = "LEADER"
end
local dead = ""
if window:dead_key_active() then
dead = "DEAD"
end
window:set_right_status(leader .. " " .. dead)
end);
return {
leader = { key="a", mods="CTRL" },
colors = {
dead_key_cursor = "orange",
},
}
```
When set, the cursor will change to this color during dead key
or leader key processing.
```lua
return {
colors = {
dead_key_cursor = "orange",
},
}
```
refs: #686
refs: #688
on macos only (for now), we generate a RawKeyEvent prior to
dead key or IME composition and route it to the window to give it
a chance to handle the event.
RawKeyEvent handling is scoped only to key assignments, not generating
input for the terminal.
A raw key event can be marked as handled to prevent moving on to
performing composition and generating cooked key input.
refs: https://github.com/wez/wezterm/issues/877
```lua
local wezterm = require 'wezterm'
return {
debug_key_events = true,
keys = {
{key="phys:Q", action=wezterm.action{SendString="woot"}},
},
}
```
The above will send "woot" to the pane whenever the key in same
physical position as Q on an ANSI standard US keyboard is pressed.
refs: https://github.com/wez/wezterm/issues/1483
This comes from a time where our quads were always locked to grid
positions. We don't need it any more: we can simply add the adjustments
to the quad positions that we set.
Removing it makes the vertex a bit smaller and reduces the amount
of GPU accessible memory we need to use.
I'm running down a weird thing where the main font renders weirdly
when the title font is 12 pt vs the main font 10 pt.
I thought there might have been a cache invalidation issue and
realized that we could have an A-B-A style issue with the font_ptr
stuff, so I replaced it with an incrementing id.
That didn't fix the thing I was looking at, but does feel a bit
nicer overall.
The default we use on macOS looks decent. Roboto is a similar
looking font that we can use for the other platforms.
I may make it the same on all three once I've had a chance
to compare it on a mac.
Previously, we would implicitly set it to the special SEQ_ZERO
value, but since that value always flags the row as changed,
it causes some over-invalidation issues downstream in wezterm.
This commit makes that parameter required, so that the code that
is creating a new Line always passes down the seqno from that event.
refs: #1472
We only need to recompute when the tab content changes, or when
the window is resized, plus invalidations of the shape cache
of texture atlas filling up.
Hover events don't need to re-shape.
We can now also place the tab bar at the bottom of the screen again.
The main tab area now takes the background color from the first
cell in a formatted tab bar item as the full background color
for the whole tab area, which looks a lot nicer than just the
using that color for the minimal bounding box of the tab text.
This commit adds a CSS box model inspired element / layout
facility, and replaces the hand implemented fancy tab bar
element render.
This makes the code for fancy tab bar much easier to read
and update.
The right status area now expands to the full height of the
tab bar area, and uses a line height of 2.0, which makes
it line up nicely in the tab bar.
Switch to the slightly more structured verbose output of `wsl -l -v`
in the hope that we are less prone to localization issues and
are more robust in the face of future changes.
refs: #1462
Rather than hardcode a fixed default value in the config crate, define
the default as optional and leave it to the font crate to compute
the value.
This is a step towards allow introducing system dependent GUI related
code to resolve/understand the title font: we can't put that directly
in the config crate.
Add `get_foreground_process_name` to both Pane and the lua wrapper.
Add `foreground_process_name` and `current_working_dir` fields to
`PaneInformation`. In order for those to be dynamically fetched,
switch the lua conversion for `PaneInformation` to be a UserData
with field access methods. It's a little more verbose but allows
us to lazily compute these two new fields.
refs: https://github.com/wez/wezterm/discussions/1421
refs: https://github.com/wez/wezterm/issues/915
refs: https://github.com/wez/wezterm/issues/876
This commit expands quick select mode so that you can trigger it
with distinct sets of patterns (eg: urls on one key assignment,
hashes on a different key assignment), different alphabets,
and lastly, the option to perform a different action from
the default copy action.
You can pair this with `action_callback` to run lua code to
do something with the selected text.
This commit also adds `wezterm.open_with`, a helper function
for opening documents/URLs.
refs: #846
refs: #1362
The label dedup code has panicked on me a couple of times.
I managed to capture the line number, so this commit aims to
capture some state to try to understand what's going on,
and importantly, to avoid the actual panic part.
refs: #1271
permits iTerm2 images to be drawn anywhere on screen without
scrolling the cursor, including the bottom row.
Also included is a check in fcwrap.rs to_range_set(), without which
was causing a panic at runtime due to subtraction from unsigned
leading to overflow.
This helps us correctly set the size of the image cell
for the case where we have a partial cell at the right/bottom
edge of an image being mapped across cells.
refs: #1270
Move away from the imprecise simple pow version and over to a
version that properly respects the linear and non-linear portions
of the curve.
refs: #1025
On Windows, both EGL and MESA render modes were too dark.
After a bit of hunting around what I found made EGL and MESA
consistent with my default nVidia GPL rendering was:
* Tell glium that our shader outputs srgb
* Add explicit gamma conversion from linear to srgb in the shader
AFAICT, that shouldn't be required, but it seems as though something
deep in glium really wants to apply some kind of gamma conversion,
and it seems to select the wrong kind unless we set things explicitly
to SRGB.
There are some people complaining about this in
https://github.com/glium/glium/issues/1615.
I actually tried to move entirely aware from the glium srgbtexture2d
type in the hope of having explicit control over the gamma, but the
issue is in what happens to the outputs rather than the inputs.
It appears to me as though the text now looks slightly less
intense, so I think this may be what we need for the gamma issue
in https://github.com/wez/wezterm/issues/544 and potentially
also https://github.com/wez/wezterm/issues/1025
refs: https://github.com/wez/wezterm/issues/1373
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
Remove special case for blocks where we switched it out for a blank
sprite and instead varied the cell background.
We now always render a matching cursor sprite as a separate layer
over the top of the text background color, but below the text
foreground layer.
This is preparing for https://github.com/wez/wezterm/issues/1432
Make bar/line cursors use the text foreground color when reverse
video cursors are enabled, per @VKondakoff:
https://github.com/wez/wezterm/issues/1076#issuecomment-978214136
Finally getting around to fixing this usability wart: this commit
changes the behavior of Window closing so that you can close a window
containing multiplexer panes without prompting and without killing
off those panes.
This is achieved through some plumbing:
* The mux can now advise Domains about an impending window closure,
giving them the opportunity to "do things" in readiness.
* The mux client domain informs the container ClientPane instances
to ignore the next Pane::kill call, which would otherwise inform
the mux server to kill the remote pane
* Pane:can_close_without_prompting now requires a CloseReason.
* ClientPane's can_close_without_prompting impl allows Window closing
without prompting on the assumption that the ignore-next-kill hack
above is working
refs: #848
refs: #917
refs: #1224
The mux client just returns a dummy reader, and some overlays
have panicking stubs: just allow for them to return None
instead of potentially spawning a useless thread.
Previously, we would only look at the `check_for_updates` config
on startup.
This commit adjusts the update checker logic so that we always
start it, and that we respect config reloads.
