A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

Wez Furlong

Last update: Jan 2, 2023

Related tags

Applications rust terminal serial terminal-emulators serial-port terminal-emulator

Overview

Wez's Terminal

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

User facing docs and guide at: https://wezfurlong.org/wezterm/

Screenshot of wezterm on macOS, running vim

Installation

https://wezfurlong.org/wezterm/installation.html

Getting help

This is a spare time project, so please bear with me. There are a couple of channels for support:

You can use the GitHub issue tracker to see if someone else has a similar issue, or to file a new one: https://github.com/wez/wezterm/issues
Start or join a thread in our GitHub Discussions; if you have general questions or want to chat with other wezterm users, you're welcome here!
There is a Matrix room via Element.io for (potentially!) real time discussions.

The GitHub Discussions and Element/Gitter rooms are better suited to questions than it is to bug reports, but don't be afraid to use whichever you are most comfortable using and we'll work it out.

Comments

Support input method editors for X11
Describe the bug

Hello Wez,

I use UIM for switching the input method to Korean. I have bound it to ctrl + alt + space. Works fine in my current terminal emulator (terminator), but not in wezterm. I only get a log message saying

2020-08-03T10:19:42.583Z ERROR wezterm_term::terminalstate > Ding! (this is the bell)

I have no idea whether this is an issue with UIM or wezterm, but I found this and thought it might be related:

FIXME in shift-space now emits space maybe?

My guess (without looking at any code and / understanding how wezterm or UIM work) would be that wezterm swallows the key presses.

Environment (please complete the following information):

OS: Linux (Debian Sid)

Version: wezterm 20200718-095447-d2315640

To Reproduce

Steps to reproduce the behavior.

Please include as much information as possible that can help to reproduce and understand the issue; some pointers and suggestions are included here in this template. You are empowered to include more or less information than is asked for here!

Configuration

Happens without a config file. Also happens with use_ime = true, but from the text that appears to only affect MacOS anywat.

Expected behavior

When I press ctrl + alt + space, UIM receives that key combination so it can switch my IM.

Screenshots

Session Recording

Additional context

Add any other context about the problem here.
enhancement Linux X11 fixed-in-nightly
opened by promisedlandt 44
Wezterm does not always notice window resize

What Operating System(s) are you seeing this problem on?

Linux X11

WezTerm version

20220514-175933-64b6e63f

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Sometimes wezterm does not recognize its window resize. Especially toggling fullscreen mostly does not work while resizing horizontally or vertically in a incremental fashion works a bit better. Please watch my screen recording.

It seems that continuously (frequently) changing window size makes wezterm notice resize events, e.g., by using mouse or by holding keys for shrinking/enlarging a window or toggling fullscreen.

I tried both my window manager's key binding and wezterm's Alt+Enter to toggle fullscreen state.

I'm using i3, specifically i3-gaps v4.20.1, as the window manager on Gentoo Linux.

To Reproduce

Launch a wezterm and resize its window.

Configuration

no config

Expected Behavior

Resizing a terminal window should affect the terminal's content area size.

Logs

wezterm-20220514-175933-64b6e63f.log

https://user-images.githubusercontent.com/158553/168458998-ad2f24ae-ca59-4995-b07f-c5f5cd15abdf.mp4

Anything else?

I bisected at release level and found that WezTerm-20210502-154244-3f7122cb-Ubuntu16.04.AppImage worked much better than WezTerm-20210814-124438-54e29167-Ubuntu16.04.AppImage. Although the former do fail to response to fullscreen toggle but much less frequently.

I've checked the release notes of the latter, it seems that the most relevant issue is only #695.
bug nvidia

opened by yuttie 38

wezterm doesn't handle bitmap fonts with strikes spread across multiple files

@wez the Terminus installation on Arch has a bunch of otb files for each strike size:

❯ fc-list | rg -i 'Terminus'
/usr/share/fonts/misc/ter-u22n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u20n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u22b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u20b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u24n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u32n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u28n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u24b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u18n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u12n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u16n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-u14n.otb: Terminus:style=Regular
/usr/share/fonts/misc/ter-x12b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x22b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x32b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x18b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x20b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x28b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x16b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x14n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x14b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x24n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x24b.pcf.gz: xos4 Terminus:style=Bold
/usr/share/fonts/misc/ter-x16n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x18n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x20n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x28n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x12n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-x22n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-u12b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-x32n.pcf.gz: xos4 Terminus:style=Regular
/usr/share/fonts/misc/ter-u16b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u14b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u18b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u32b.otb: Terminus:style=Bold
/usr/share/fonts/misc/ter-u28b.otb: Terminus:style=Bold

Problem is that on wezterm, no matter what font_size I set for Terminus, I always get the smallest sized one. I don't have similar problem with Alacritty. I'm trying setting values after pt2px conversion to no avail as well (I have 96 dpi).

FWIW, I'm trying to replicate this, not sure whether it's possible at all on wezterm.

Originally posted by @oblitum in https://github.com/wez/wezterm/issues/1165#issuecomment-932732562

opened by wez 34

Crash with wayland enabled on Gnome Wayland and display scaling enabled

What Operating System(s) are you seeing this problem on?

Linux Wayland

WezTerm version

wezterm 20220317-165235-27088fab

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Unsupported modifier, resource creation failed.
XXX: resource creation failed
 2022-03-18T01:41:36.947Z INFO  wezterm_gui::termwindow        > OpenGL initialized! Mesa Intel(R) UHD Graphics (CML GT2) 4.6 (Compatibility Profile) Mesa 22.0.0 is_context_loss_possible=false wezterm version: 20220317-165235-27088fab
Unsupported modifier, resource creation failed.
XXX: resource creation failed
 2022-03-18T01:41:37.042Z ERROR wezterm_gui                    > Error while flushing display: Broken pipe (os error 32); terminating
thread 'main' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/thread/local.rs:388:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fish: Job 1, 'cargo run --release --bin wezte…' terminated by signal SIGILL (Illegal instruction)```

### To Reproduce

1. Enable wayland
2. Attempt to launch the application

### Configuration

local wezterm = require 'wezterm';

return {
    enable_wayland = true,
}


### Expected Behavior

Application launches and displays a window

### Logs

_No response_

### Anything else?

_No response_

bug Wayland fixed-in-nightly

opened by szbergeron 31

Maximizing leads to crash

Describe the bug

Maximize => crash, "X11 connection is broken: ClosedReqLenExceed"

Environment (please complete the following information):

Ubuntu 20.04, GNOME

To Reproduce

Maximize.

Configuration

local wezterm = require 'wezterm';

return {
  font = wezterm.font("Fira Code Nerd Font"),

  font_size = 14.0,
  font_antialias = "Subpixel",
  font_hinting = "Full",

  dpi = 96.0,

  color_scheme = "Afterglow",

  keys = {
     {key="1", mods="ALT", action=wezterm.action{ActivateTab=0}},
     {key="2", mods="ALT", action=wezterm.action{ActivateTab=1}},
     {key="3", mods="ALT", action=wezterm.action{ActivateTab=2}},
     {key="4", mods="ALT", action=wezterm.action{ActivateTab=3}},
     {key="5", mods="ALT", action=wezterm.action{ActivateTab=4}},
     {key="6", mods="ALT", action=wezterm.action{ActivateTab=5}},
     {key="7", mods="ALT", action=wezterm.action{ActivateTab=6}},
     {key="8", mods="ALT", action=wezterm.action{ActivateTab=7}},
     {key="9", mods="ALT", action=wezterm.action{ActivateTab=8}},
     {key="Tab", mods="CTRL", action=wezterm.action{ActivateTabRelative=1}},
     {key="Tab", mods="CTRL|SHIFT", action=wezterm.action{ActivateTabRelative=-1}},
     {key="0", mods="CTRL", action="ResetFontSize"},
     {key="+", mods="CTRL", action="IncreaseFontSize"},
     {key="-", mods="CTRL", action="DecreaseFontSize"},
  }
}

Expected behavior

Window maximized

Screenshots

Additional context

Have a GNOME extension, Pixel Saver that puts window border icons (close/maximize/minimize) in the GNOME top bar, perhaps that causes X to return something unexpected to wezterm.

bug X11

opened by dsvensson 31

Two Applications Opening on OpenSUSE Repo Varient

What Operating System(s) are you seeing this problem on?

Linux Wayland

WezTerm version

20220408.101518.b908e2dd~232-1.1

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

I have installed the wezterm application from the opensuse repository. When I open the application, two applications appear on my task manager, WezTerm and wezterm-gui.

Also, the opensuse repository is not up to date. Thank you!

To Reproduce

No response

Configuration

-- WezTerm -- https://wezfurlong.org/wezterm/

local wezterm = require 'wezterm'

return { default_prog = {"/usr/bin/zsh", "-l"},

check_for_updates = false,

color_scheme= "nord",

window_background_opacity = 0.90, initial_rows = 30, initial_cols = 130,

font = wezterm.font("MonoLisa Nerd Font"), font_size=12,

-- Cursor style default_cursor_style = 'BlinkingBar',

-- Enable CSI u mode -- https://wezfurlong.org/wezterm/config/lua/config/enable_csi_u_key_encoding.html enable_csi_u_key_encoding = true

}

Expected Behavior

When I open my application it should say just WezTerm is running instead of opening a separate application called wezterm-gui

Logs

No response

Anything else?

https://i.imgur.com/f4mSmLc.pn

Thank you so much for the help! Love the terminal otherwise though :)
bug

opened by epswims 27
vttest
Describe the bug

Are you using vttest ? It is a great way to test your terminal features. Some of them fails now.

Also maybe this comment might help.

Environment (please complete the following information):

macOS 10.15.2 (19C57)

Frontend: not sure

20200113-222147-724ad3a

To Reproduce

Download vttest from: https://invisible-island.net/vttest/

run vttest from terminal

press 1 to run the first test. press Enter several times to skip to next test and show errors.
bug
opened by erf 27
Change color of tab depending on pane feature

Is your feature request related to a problem? Please describe.

I use toolbox to run certain things at work and it looks more or less the same as my regular account. I do use starship to change the prompt, but it would be amazing if the tab could also indicate that this tab runs in toolbox.

Describe the solution you'd like It would be amazing if wezterm could change to color/add a prefix of the tab based on the tab title or an env variable or a file or so (the actual flag is the existence of a file but I think I can set a env variable or use a title command to change the tab title).

Describe alternatives you've considered As far as I understand the config (https://wezfurlong.org/wezterm/config/lua/config/tab_bar_style.html) does not allow for context based styling of specific panes.

One alternative is using the right status, as pane:get_title() exists. But that doesn't show non-active tab(s) which run in that environment.
enhancement fixed-in-nightly waiting-on-op

opened by jankatins 26
Add config option to always open window in full screen/maximized

Is your feature request related to a problem? Please describe. When using wezterm on laptop, the window size is too small and I have to maximize the window everytime.

Describe the solution you'd like It would be really nice, if it there is a configuration option to always open the window in full screen/maximized.

Describe alternatives you've considered Similar behaviour can be obtained by setting initial_rows and initial_cols, but needs to be configured per machine/monitor.

Additional context

#256 #177
enhancement fixed-in-nightly

opened by JoyceBabu 26
CPU usage rises until reload

What Operating System(s) are you seeing this problem on?

Windows, FreeBSD X11

WezTerm version

20220319-142410-0fcdea07

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

First off, just want to say that I've used a bunch of terminals over the years and this is my favorite terminal by far. Keep up the good work and hopefully I'll be able to contribute in the future someday :) Now, onto the issue...

I've noticed that wezterm-gui will start to eat up more and more CPU usage over time. It doesn't seem to happen all of a sudden, but the average utilization seems to climb higher and higher. I realize it after I've noticed that my CLI has become slower and slower. I'll switch to the htop tab and see wezterm-gui at the top. I'll hit Ctrl+Shift+R to reload the config and the CPU usage subsides quickly after that. It's strange.

I have three workstations (freebsd/amd64, win10/amd64, & macOS/arm64). I haven't noticed it on macOS yet, but I rarely use wezterm directly on there (mainly just Windows + FreeBSD). I've only really noticed it on FreeBSD, but that happens to be my primary workstation.

The fact that it builds up slowly and then subsides on config reload makes me wonder if it's accumulating file handles or whatnot. I haven't looked at the source for wezterm and don't know which crates it's using, but assuming that underneath it's using kqueue() to watch config files, FreeBSD has a known issue where it has to open a fd for each file being watched (whereas inotify just creates a watcher on the root directory).

When I started writing this post I did a reload of the wezterm config and wezterm-gui CPU utilization was at 0.2%. Over the past few minutes it has risen to 10% with no interaction with wezterm. It's strange.

To Reproduce

Unsure, as I don't even know when or how it's triggered.

Configuration

animation_fps = 1 cursor_blink_ease_in = "Linear" cursor_blink_ease_out = "Linear"

Expected Behavior

CPU usage remains <1% at idle.

Logs

14:19:21.471 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1 14:19:37.095 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1 17:37:56.570 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 17:37:58.824 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 17:38:08.018 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 18:27:53.003 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:27:53.004 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:31.712 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:31.713 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:43.346 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:43.347 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:52.629 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:52.629 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:44:25.816 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1

Anything else?

No response
bug

opened by xorander00 25
Text is brighter than the previous release
Describe the bug

After getting a "new release" notification today, I switched from a version from June (wezterm-git (wezterm.ssh.0.1.1.120.g20c4dcdc-1)) to a nightly build (wezterm-nightly-bin (20210815.182117.ab21910d-1)). I immediately noticed multiple changes to how the content is rendered, compared to instances of the previous version I still have running.

The cursor sometimes has "fuzzy" edges, compared to the previously sharp edges.

With my custom "Gruvbox Light Soft" colour scheme, this happens for active panels, while the inactive ones are fine

With the default colour scheme, it's the other way around

Text is now bold(er) and colours have changed slightly

Contrary to the text getting bolder, the character used to render the separator between panes is now thinner. It's also used in Kakoune, where the change is the same.

Dimming for inactive panes doesn't affect the background colour any more. Only the text colour changes.

It does work again when the inactive pane is running Kakoune.

Environment:

OS: Linux X11

Version: wezterm 20210815-182117-ab21910d

Configuration

Font settings:

font = wezterm.font("Hack Nerd Font"), font_size = 14,

Colour Scheme:

# Gruvbox Light Soft [colors] background = "#f2e5bc" foreground = "#3c3836" cursor_bg = "#3c3836" cursor_border = "#f2e5bc" cursor_fg = "#f2e5bc" # black, red, green, yellow, blue, purple, teal, white ansi = ["#282828","#cc241d","#98971a","#d79921","#458588","#b16286","#689d6a","#928374"] brights = ["#7c6f64","#9d0006","#79740a","#b57614","#076678","#8f3f71","#427b58","#7c6f64"]

Screenshots

Fuzzy cursor:

Bold text, different colours: Old version is top.

Active vs Dimmed: Active is top.
bug
opened by sclu1034 25
Mouse selection with Shift inconsistent
What Operating System(s) are you seeing this problem on?

Windows, Linux X11, Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Window 10, Fedora 37 with GNOME.

WezTerm version

20221231-234404-7c886744

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When I select test with the mouse while holding Shift, I always expect that a new area would be selected. That's the behavior of most Linux terminals, such as xterm and gnome-terminal. That's also the Putty behavior on Windows, WezTerm is inconsistent in its behavior. If the application in the terminal is using the mouse (e.g. Midnight Commander), I get the expected behavior. Otherwise (e.g. bash), WezTerm is extending the existing selection if there is one. Worse yet, WezTerm would "extend" the selection if there is none; the other point is where I last clicked the mouse. Extending the selection is a behavior that I never expect. Over the years of using various Linux terminals, I got accustomed to the a simple, consistent behavior - when I'm holding Shift, the mouse copies whatever I select, whether I'm running a mouse aware application or not. I noticed that behavior on Windows first and them verified that it exists on Linux as well, bot with Wayland and X11.

To Reproduce

Run WezTerm

Select a word with the mouse

While holding Shift, try selecting another word

Configuration

bypass_mouse_reporting_modifiers = 'SHIFT',

Expected Behavior

The new word is selected. No other text is selected.

Logs

Not sure it's relevant, these are the only logs I'm seeing

23:59:53.445 WARN wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented 00:00:13.816 WARN wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented 00:00:21.799 WARN wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented

Anything else?

I had to move my development from Linux to Windows recently due to VPN requirements, and I really need a terminal that would allow me to work as before without relearning, especially because I'm still using Linux computers when not on VPN. There are many good Windows terminal emulators that don't implement mouse copy with Shift correctly. WezTerm is almost there, but it's still letting me down when I'm not running Midnight Commander.
bug
opened by proski 0
Wezterm window glitches and lags behind cursor when moved between 2 windows on 150% window scale
What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

Windows, scale: 150% display 1: 2560 x 1440 display 2: 1680 x 1050

WezTerm version

20221227-101049-8b05fdba

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Wezterm window glitches and lags behind cursor when moved between 2 windows on 150% window scale. The issue is not present on 100% scale or with any other programs I tried. https://user-images.githubusercontent.com/46792251/210055956-e780424b-3439-4618-a684-72b76e1dd68f.mp4

To Reproduce

Have 2 different screens, side by side, with different resolutions and windows scale at 150%. Move Wezterm window between them.

Configuration

local wezterm = require 'wezterm'

return { font = wezterm.font 'Fira Code', default_prog = { 'C:\Program Files\PowerShell\7\pwsh.exe', '-NoLogo' }, color_scheme = "Dracula (Official)", harfbuzz_features = { 'calt=0', 'clig=0', 'liga=0' }, -- Start-Process wezterm pwsh -Verb runAs

use_fancy_tab_bar = false,

window_frame = { -- The font used in the tab bar. -- Roboto Bold is the default; this font is bundled -- The size of the font in the tab bar. -- Default to 10. on Windows but 12.0 on other systems font_size = 10.0,

-- The overall background color of the tab bar when -- the window is focused active_titlebar_bg = '#333333', -- The overall background color of the tab bar when -- the window is not focused inactive_titlebar_bg = '#333333',

},

colors = { tab_bar = { inactive_tab_edge = '#575757', }, }, ssh_domains = {}, }

Expected Behavior

No response

Logs

No response

Anything else?

No response
bug
opened by anzepintar 1
wezterm record - paste clipboard inserts additional chars at random positions
What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20221122-154621-68c754b1

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

if i paste from system clipbard something into the terminal while recording the session the content is been destroyed with multiple chars at different positions.

To Reproduce

start a new wezterm wezterm -n start to get a clean configuration (I also unregistered clink)

start a new record session inside this terminal wezterm record

copy a new text to system clipboard (e.g. with notepad.exe), in my example TestTestTest

press <ctrl><shift><v> to paste it

it will produce TestT1;1;0;1_stTes_Test

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response
bug
opened by Grueslayer 0
wezterm imgcat with vifm
What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20221122-154621-68c754b1

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

wezterm and vifm using imgcat don't work quite well together, some behaviour maybe is Windows specific other maybe a global issue.

adding this to vifmrc will add a preview (when using :view in vifm) for picture files

fileviewer {*.bmp,*.jpg,*.jpeg,*.png,*.gif,*.xpm},<image/*> \ wezterm imgcat --width %pw --height %ph %c:p %pd

for windows maybe using escaped filepath is better

fileviewer {*.bmp,*.jpg,*.jpeg,*.png,*.gif,*.xpm},<image/*> \ wezterm imgcat --width %pw --height %ph %"c:p %pd

On MacOS it will correctly displays the image but the file list pane will get corrupted. Maybe that can be fixed by not changing the cursor?

So we need to add an option to wezterm imgcat. By the way, it would be nice to have the upper left position X/Y also as new parameters like imgcat support.

On Windows it looks quite different: No image (or any other thing) is been displayed, the area keeps empty. Calling wezterm imgcat with the same parameters diplays it the right way.

So I can only assume

a) it is been displayed outside the area (because vifm has a different cursor position on windows, so having x/y as parameter like described above may help) b) vifm has a different / alternative screen area than wezterm uses

Would be fine to fix both things (maybe we need the help from vifm maintainer).

I can help to setup vifm for testing purposes on your system.

To Reproduce

No response

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response
bug
opened by Grueslayer 2

High cpu usage for Xorg

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

i3-gaps. I tried with lightdm and gdm - the same.

WezTerm version

20221225-233013-ff2caf4f

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When i open wezterm, Xorg uses a lot of cpu resource. It doesn't always happen right away, sometimes after a while. And value of cpu usage gradually increases before 100%. I see freezes in wezterm in the same time.

It doesn't happen with alacritty and kitty. It doesn't happen in gnome ubuntu, only when i use i3wm.

To Reproduce

No response

Configuration

local wezterm = require 'wezterm'

-- FONTS --

local font = function(name, params)
  local names = {
    name,
    'Iosevka Nerd Font',
  }

  return wezterm.font_with_fallback(names, params)
end

local font_config = ({
  jet_brains = {
    font_size = 9.5,
    font = wezterm.font('JetBrainsMono Nerd Font'),
    cell_width = 0.87,
    font_rules = {
      {
        font = wezterm.font('JetBrainsMono Nerd Font', { weight = 'Medium' }),
      },
    },
    line_height = 0.9,
  },
  iosevka = {
    font_size = 10.7,
    font = wezterm.font('Iosevka Nerd Font'),
    line_height = 0.9,
    font_rules = {
      {
        font = font('Iosevka Nerd Font', { italic = false, weight = 'Medium' })
      }
    }
  },
  victor_mono = {
    font_size = 10,
    font = font('VictorMono'),
    line_height = 0.80,
    font_rules = {
      {
        font = font('VictorMono', { italic = false })
      }
    }
  },
  caskaydia = {
    font_size = 10.2,
    line_height = 1,
    cell_width = 1,
    font = wezterm.font('CaskaydiaCovePL Nerd Font'),
    font_rules = {
      {
        italic = true,
        font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
      },
      {
        intensity = 'Bold',
        font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
      },
      {
        font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
      }
    }
  },
  mononoki = {
    font_size = 10.3,
    font = font 'mononoki Nerd Font',
    cell_width = 0.87,
    line_height = 1,
    font_rules = {
      {
        font = font('mononoki Nerd Font', { italic = false, weight = 'Bold' })
      }
    }
  },
  fira = {
    font_size = 9.4,
    font = wezterm.font 'FiraCode Nerd Font',
    line_height = 1,
    cell_width = 0.83,
    font_rules = {
      {
        font = wezterm.font('FiraCode Nerd Font', { italic = false, weight = 'Medium' })
      }
    }
  },
  hack = {
    font_size = 10.2,
    font = font 'Hack Nerd Font',
    line_height = 1,
    font_rules = {
      {
        font = wezterm.font('Hack Nerd Font', { italic = false, weight = 'Regular' })
      }
    }
  },
}).jet_brains

-- UTILS --

local merge = function(list)
  local result = list[1]

  for i = 2, #list do
    for key, value in pairs(list[i]) do
      result[key] = value
    end
  end

  return result
end

-- EVENTS --

wezterm.on('gui-startup', function(cmd)
  local _, _, window = wezterm.mux.spawn_window(cmd or {})
  window:gui_window():maximize()
end)

-- THEME --

local colors = {
  foreground = "#787C99",
  background = "#202837",
  cursor_bg = "#ffcc66",
  cursor_border = "#ffcc66",
  cursor_fg = "#404060",
  selection_fg = "#333355",
  selection_bg = "#787c99",
  scrollbar_thumb = "#222222",
  compose_cursor = "orange",
  ansi = {
    '#404060',
    '#F7768E',
    '#9CC4B2',
    '#88C0D0',
    '#6e88a6',
    '#9398cf',
    '#c8ae9d',
    '#E5E9F0',
  },
  brights = {
    '#9CC4B2',
    '#F7768E',
    '#9CC4B2',
    '#ffcc66',
    '#6e88a6',
    '#9398cf',
    '#c8ae9d',
    '#ACB0D0',
  },
}

local padding = {
  left = 0,
  right = 0,
  top = 0,
  bottom = 0,
}

-- RESULT --

local config = {
  colors = colors,
  window_padding = padding,
  enable_tab_bar = false,
  scrollback_lines = 10000,
  cursor_blink_rate = 700,
  max_fps = 60,
  animation_fps = 30,
  window_background_opacity = 0.93,
  enable_kitty_graphics = true,
  default_cursor_style = 'BlinkingBlock',
  freetype_load_target = 'HorizontalLcd',
}

return merge {
  config,
  font_config,
}