This adds string serialization for the keycode and modifiers as
used in the config.
We can't simply tell the base types to serialize in this form because
we may serialize and pass those via the mux protocol and the default
derived serializers are more efficient for that purpose.
This allows:
```lua
local wezterm = require 'wezterm'
return {
keys = {
{key="a", mods="ALT", action=wezterm.action{SendKey={key="b"}}}
},
}
```
to parse: previously, wrapping `SendKey` in `wezterm.action` would fail
to round-trip the the `SendKey` and lead to an error loading the
config.
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.
ConPTY emits a sequence that sets the title to the name of the
program that is initially launched into it.
This commit tries to ignore that sequence in that circumstance,
so that the logic in b5d156c282
can more dynamically set the tab title.
If the pane title is the default `wezterm`, then return the
process basename instead. This makes the tab titles more useful
by default, although on Windows, conpty will set the title
to the initial executable path and defeat this.
There was a discrepancy between leaving it out of the config
and having it partially initialized; fix that up.
Make the default title font size larger on !Windows, as it
looks a bit better.
We might need to make this larger size mac specific.
refs: #1180
Poking around at an issue, and thinking that some more context
might be nice.
Haven't managed to reproduce the issue so far though :-/
refs: https://github.com/wez/wezterm/issues/1156
Previously, we'd set it to 100% if any non-zero channel was present,
but this resulted in stronger/darker outlines that were especially
noticeable when the window background was transparent and over a
bright background.
This commit sets the alpha based on the coverage provided to us
by freetype and looks better with and without a transparent window
background.
@dmfay: I think this might be behind what you noticed in your last
comment on #1025.
refs: #1325
Not 100% sure why this only really manifested on Windows, but
the symptoms were:
* Run powershell in a tab
* Run `dir`
* Hit enter a couple of times to show a couple of prompts
* Try using the mouse to select across the prompt boundaries
The selection would get invalidated crossing the boundaries.
I traced this down to the lines around those regions having
SEQ_ZERO as their sequence, so this commit ensures that lines
that are created as part of scrolling the screen are correctly
tagged with the current seqno from the terminal display.
Why only windows? Not totally sure; perhaps it is related to
something funky happening in the conpty layer and sending us
unusual escapes (eg: scroll margins?)
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 is really a timing issue: if shift-click extension of the mouse
selection is used, the user may release the mouse button slightly
after the SHIFT key (which is fine) or vice versa (which was not
previously matched)
refs: #1204
This isn't ideal, as we're discarding information, but in #1422
where the problem codepoint is a unicode bidi control, we can't and
don't use that information anyway.
We'll need to figure out how to incorporate that when we get to it.
For now, this makes the presentation work correctly.
refs: #1422
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
