This is definitely in the band-aid category, but two issues have
mentioned the AA in custom block glyphs recently.
This commit adds an `anti_alias_custom_block_glyphs` option that can be
set to false to prevent the custom block glyphs from enabling AA.
I think a better long term fix would be some kind of hinting to avoid
the degenerate AA case, but when I made an enquiry about this class of
issue in tiny skia in the past, the author didn't want to diverge from
skia-compatible behavior, so I think we'd need to find (or build!) an
alternative rasterizer for these path instructions.
refs: https://github.com/wez/wezterm/issues/1753
refs: #1817
To fix this correctly, the mux protocol would need to have some
special cases for talk to a gui server implementation, and we don't
have those today.
refs: #1794
The keys section was way too big; this splits it up into more
manageable pieces, adds a nice flow chart to show how key events
are processed and adds an example of using the new key tables feature.
The glium IncompatibleOpenGl Display doesn't include any of the
useful context to explain what the issue was, so this commit
renders the error both in human friendly and Debug form to
see if we can understand more about what is happening.
refs: https://github.com/wez/wezterm/issues/1813
We were pinned on the revision where I had added dual source blending,
because I wanted that feature ahead of the crate being published.
Since then a couple of releases have been made so we can unpin.
On Windows 11, we had a report of glium complaining about the opengl
version. I can't find that error message string in the current version
of the code so it's possible that that situation has been resolved.
refs: https://github.com/wez/wezterm/issues/1813
This is a bit more compact and easier to edit.
A downside is that the search engine highlight can break the diagram and
cause it to emit a syntax error.
* gui: improve mouse text selection
* implement mouse press capture between the terminal and UI, so when you
start selecting text from the terminal the tabs won't activate and
vice-versa
* selecting from the top and bottom lines won't scroll the viewport
anymore, it will only scroll if the mouse is moved out of line bounds
* change cell selection so that it behaves like text selection usually
does in other popular software
refs: https://github.com/wez/wezterm/issues/1199
refs: https://github.com/wez/wezterm/issues/1386
refs: https://github.com/wez/wezterm/issues/354
`ActivateKeyTable` pushes a new named key table entry onto the stack.
It has some parameters:
* name - required; the name of a entry in `key_tables` that should be
activated.
* timeout_milliseconds - how long the entry should remain active.
When this duration elapses, the entry will pop itself from the
stack. If omitted, the entry will not pop itself due to time.
* one_shot - if true (or omitted; true is default), the entry will pop
itself after one use. If false the entry will not pop itself after use.
But note that if timeout_milliseconds is set then it may pop itself
due to time.
* replace_current - if true, will pop the current stack entry before
activating the current entry. Most useful when combined with some
other one_shot=false activation.
`PopKeyTable` explicitly pops the top of the key table stack.
Most useful with `one_shot=false` activations.
`ClearKeyTableStack` clears the key table stack. Most useful with
`one_shot=false` activations.
```
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
local name = window:active_key_table()
if name then
name = "TABLE: " .. name
end
window:set_right_status(name or "")
end);
return {
debug_key_events = true,
keys = {
-- Activate the "woot" table as a one-shot with
-- a 2 second timeout, after which it will restore
-- the default table.
{
key="a", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
timeout_milliseconds=2000,
}
}
},
-- Activate the "woot" table.
-- The table will remain active until explicitly popped
-- by the `PopKeyTable` action. See the Escape binding below!
{
key="b", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
one_shot = false,
}
}
},
-- Activate the "woot" table as a one-shot with
-- no timeout. It will remain active until a key is pressed,
-- after which is will restore the default table.
{
key="c", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
}
}
},
},
key_tables = {
woot = {
{key="a", action=wezterm.action{SendString="woot"}},
{key="Escape", action="PopKeyTable"},
},
},
}
```
This commit introduces a new `key_tables` config option that allows
defining named groups of key assignments, but that have no effect yet.
To support this change, the InputMap type has been adjusted to allow
for the idea that multiple tables can exist.
refs: https://github.com/wez/wezterm/discussions/1812
* termwiz: add support for kitty image using shm mode
* termwiz: kitty image shm cleanup error handling
* termwiz: kitty image shm create wrapper for HANDLE and impl Drop for it
* termwiz: kitty image shm refactor windows implementation
Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
The gist of the issue is that when setting eg: scale=1.2 to draw
a larger CJK glyph, it is drawn at the same descender level, which
makes it more likely to leave the top of the cell.
This commit adjusts the y position by the difference between the
original and the scaled descender so that is less likely to cause
problems.
refs: https://github.com/wez/wezterm/issues/1803
This is mostly a refactoring: pulling out the discrete width/height from
the `new_window` method and preparing to pass down x/y coords as well.
The types are expressed as Dimension so that screen relative sizes could
be expressed in the future... once we know how to obtain that
information on each platform.
refs: https://github.com/wez/wezterm/issues/1794
The tab bar height could vary by a couple of pixels depending on the
text shown inside it, which results in visual jitter as the title bar
changes.
Avoid that: always return our constant reserved amount of space for the
tab bar, even if it means that there are a couple of pixels "wasted".
cc: @davidrios
A bit of a PITA, this commit:
* Introduces a DeferredKeyCode type that defers resolving a concrete
keycode
* Adds key_map_preference config which can be Mapped or Physical
* Key map building resolves the keycode using key_map_preference
* Default key assignments have been re-phrased in order to produce
DeferredKeyCodes
* User-specified keys without `mapped:` or `phys:` prefixes will
resolve according to key_map_preference
refs: https://github.com/wez/wezterm/issues/1788
refs: https://github.com/wez/wezterm/issues/1784
Previously, we'd create a clipboard handler associated with a GUI window
and take care to pass that down to the underlying Pane whenever we
spawned a new pane.
For the mux server, instead of being associated with a GUI window, the
clipboard was a special RemoteClipboard that would send a PDU through
to the client that spawned the window.
The bug here was that when that client went away, the clipboard for
that window was broken.
If the mux server was the built-in mux in a gui process this could
leave a tab without working OSC 52 clipboard support.
This commit restructures things so that the Mux is responsible for
assigning a clipboard handler that rephrases the clipboard event
as a MuxNotification.
Both the GUI frontend and the mux server dispatcher already listen
for mux notifications and translate those events into appropriate
operations on the system clipboard or Pdus to send to the client(s).
refs: #1790
