Wez Furlong
Wez Furlong
It sounds like things are actually working correctly: setting the `XCURSOR_THEME` does work and respects what you've configured. The heart of the issue is that wayland doesn't have a way...
With the commit that I just pushed, you can move your workaround into your lua config: ```lua local wezterm = require 'wezterm' local xcursor_size = nil local xcursor_theme = nil...
`main` is now technically capable of talking to [XDG Desktop Portal](https://flatpak.github.io/xdg-desktop-portal/) to query these sorts of settings. The settings interface currently only portably defines the dark mode/appearance in a DE-agnostic...
It's not actually a bug; the parsing/interpretation is compatible with https://linux.die.net/man/3/xparsecolor which explicitly defines the behavior this way. We're compatible with xparsecolor so that we match xterm's behavior when processing...
Possibly another manifestation of https://github.com/wez/wezterm/issues/2297
Might be helpful to run wezterm with `WAYLAND_DEBUG=1` set in the environment and see if there's additional info about what's happening at the wayland level.
Can you try running with `WAYLAND_DEBUG=1` set and report back if/when it happens again?
> I also sometimes feel that for local terminals the prediction in mux is causing these laggy scrolling as it predicts `j`,`k` not as editor movements: @Mic92 Are you using...
@Mic92 I'd like to treat the multiplexer performance as distinct from this issue; we can use #867 to track that. This issue (#817) is due to the GUI render cost...