What makes wezterm bad?

[exastone]

Hold up, before getting defensive I'm asking "what make wezterm not the best terminal emulator?"
I think wezterm might be the best terminal emulator currently and surprised it hasn't gained more attention, I was wondering what are the biggest limitations at the moment?

[jrmoulton]

I haven't found any limitations. It's great

[exastone]

It does seem pretty darn good, and i haven't come across anything besides the odd tweak here and there can't be addressed in the config file. I've seen some posts around attempting to benchmark performance of various terminal emulators (wezterm is usually not included in the comparison) and most of which provide the disclaimer that it's not a trivial task to provide an apples to apple comparison.

Alacrity has vtebench tool for benchmarking terminal emulator PTY read performance, I guess a better question would be has anyone had a go a benchmarking wezterm and found anything interesting?

[lifeym]

Thers's a benchmarking on Warp's official website: https://docs.warp.dev/how-does-warp-compare/performance
Though I don't care about it, but looks like performance isnot the pros of wezterm.

Seems Alacrity has the best performance just now, and some feaurs are similar to wezterm, but it's not stable enough, even I cannot get it work on my windows 11 and mac.
I'm indeed like the vi like key binding and lua configuration. wezterm is great.

[robrecord]

It's pretty hard to get started, especially to make it look good - that was my experience.

Also the promise of multiplexing isn't quite delivered. I'm still trying to figure out how to fit my tmux workflow into WezTerm (session persistence, having more than one session open at once...)

[ema2159]

As per the customization, it is quite good and easy. You cannot compare it with other "out of the box" terminal emulators, but rather other highly customizable terminal emulators (Alacritty, Kitty). Lua is a fantastic language for configuration and extension, and compared to Kitty and Alacritty, I found Wezterm extremely easy to configure.

It also comes with a sensible font default (JetBrains Mono) which makes it look nice out of the box too.

[EarlGray]

Memory consumption: on my machine right now, it's ~170 MB of resident memory vs ~80 MB for Alacritty.

Some time ago I could feel noticeable delay for events. I suspected this was due to the smol executor or event handlers in Lua. This is not a real issue anymore.

Customizability is great, but it can have downsides in resource consumption and response latency if left unchecked.

Also, it felt weirdly out of place on Mac. I could not quite put my finger on what exactly was wrong, but it did not feel integrated at all (non-mac font rendering? non-mac keyboard shortcuts? drag-and-drop not working as expected?), so much that I had to switch back to Terminal.

[eugenesvk]

Is higher memory use because of customizability??

[kalocsaibotond]

Yes, memory and resource consumption is the greatest weakness of WezTerm. It is even worse with WebGpu frontend. With that, WezTerm reaches a whopping ~320 MB of resident memory (while Alacritty for me uses a ~50 MB consistently out of box).

I don't think that this resource requirement comes from customisability, since lua is a tiny language. Lua gives the amazing configurability of WezTerm (and its lua api). The lua interpreter ought not to occupy more than 1 MB memory.

It would be nice to have configuration options that strips down all the fancy overhead, decrease resource use, and augments performance to a ConEmu level.
Considering, the fact that how surprisingly popular the suckless simple terminal is, there are many people who would be satisfied with a minimalistic, but performant terminal emulator that can render nerd fonts quickly.

[AndydeCleyre]

I love wezterm. Here's what I don't like:

• The configuration being in a full programming language (lua), rather than a configuration language (e.g YAML, TOML, JSON5, HJSON, NestedText, UCL). This also hinders querying or modifying the configuration from other code.
• All the default shortcuts that I need to explicitly disable in the config. I keep adding as I find interference problems, but so far:

    keys = {
      {key="Enter",      mods="ALT",        action="DisableDefaultAssignment"},
      {key="f",          mods="CTRL",       action="DisableDefaultAssignment"},
      {key="f",          mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="k",          mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="LeftArrow",  mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="RightArrow", mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="UpArrow",    mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="DownArrow",  mods="CTRL|SHIFT", action="DisableDefaultAssignment"},
      {key="PageUp",     mods="SHIFT",      action="DisableDefaultAssignment"},
      {key="PageDown",   mods="SHIFT",      action="DisableDefaultAssignment"},
    },

But really it's fantastic.

[wez]

you can read files in lua and parse the contents.
There is a builtin json parser: https://wezfurlong.org/wezterm/config/lua/wezterm/json_parse.html
There is a PR to add yaml and toml: #4969

[AndydeCleyre]

you can read files in lua and parse the contents.
There is a builtin json parser: https://wezfurlong.org/wezterm/config/lua/wezterm/json_parse.html
There is a PR to add yaml and toml: #4969

Thanks! My truth sources are not those formats, but this does open the door for me to generate such a file, then import that.

[wez]

lua also has built-in file io functions that you can use to implement any file format if you prefer. You can google and find a lot of examples of how to read files in lua

[AndydeCleyre]

I'll note that this still is not ideal, as I'd like to be able to produce a single wezterm config file that can be copied around in a complete form, without relying on any external files or programs.

So I could turn my wezterm "config" file (which is really a program) into a template file, only edit that directly, and generate the wezterm.lua as output.

Another downside of suggested alternatives is of course that not everyone who wants to configure Wezterm also wants to learn to develop Lua programs.

[AndydeCleyre]

Well if anyone else struggles to manage the verbosity and complexity of writing lua to reconfigure wezterm, I've made myself a template for wezterm.lua and now regenerate it after editing a vars.nt config file. So far, so good.

[eugenesvk]

I'm not sure what the biggest limitations to getting more attention are (I also think it's the best terminal out there), so will just list a few of areas for improvement:

• lua is too simplistic of a language for anything but simplistic customizations, and the ability for more complex customization is what makes WezTerm great! Ideally WezTerm would have some WASM plugin host instead so you could use any language with a wide ecosystem available.

  • For example, since I dislike the unreadable hex color syntax codes for setting terminal color theme, I wanted to be able to use something nice like OKHSL, but then there was no lua package, so had to port
  • It's especially bad when you want to tweak a thing or two in your config after a while and have to relearn all the lua language design issues again

• more ergonomic keybindings customizations would be nice as it's easy to get lost in the layers (though stacked approach is great in itself)

• memory use could maybe be lower (though I'm not sure I'd trade any functionality to achieve that :) )

[eugenesvk]

You should be able to use most CSS color syntaxes

None of them are good :) afaik CSS v4 only supports oklch, but not okHSL/V w3c/csswg-drafts#8659

I've checked the methods on https://wezfurlong.org/wezterm/config/lua/color/index.html#available-methods and there doesn't seem to be okhsl/v either

Anyway, the syntax I use, which allows me to use the minimum pure vertically aligned numbers and to:

• set a global default color space
• have per-color overrides (e.g., okhsv 29 100 100 instead of okhsl to emphasize the max values)
• optional niceties like ° indicators that get stripped on parsing (CSS supports the old-school deg, but they'll likely never get to this kind of visual pleasantries)

local colSpaceDef	= "okhsl"	-- treat all (non-prefixed) triplet numbers as HSL
local colSpaces  	= {"hex","hsl","hsv","hwb","okhsl","okhsv"} -- allowed color spaces (prepend with ␠ or :)

local col         	= {}
col.background    	= "        0   0   5"	-- okHSL due to colSpaceDef
col.cursor_bg     	= "      227 100  74"	-- 
col.visual_bell   	= "okhsv  29 100 100"	-- hsV to emphasize the 100 (okHSL = 29 100 57)
col.compose_cursor	= "hsl    38 100  50"	-- copy paste from another scheme, haven't converted

(we've discussed the lack of global prefixes in this issue #1436 that links to some older version of my lua converter)

[solowdev]

"lua is too simplistic of a language for anything but simplistic customizations"

I don't think this statement is quite fair. Lua is often used in game dev for its simplicity in extending a game. Every game in Roblox is made in Lua and some are actually pretty neat (check out FRONTLINES). Every Interface addon in WoW is made in Lua, and you have some complete GUI overhauls. On a software closer to wezterm, AwesomeWM config is in Lua, and the amount of things you can do on this window manager is quite crazy.

I understand you might not like the language. It has its limitations, and if you don't like the logic of "everything is a table" well... you're doomed. But it is a very powerful language to make things with really!

[eugenesvk]

The fact that powerful things can be built doesn't negate the argument that the language doesn't help you do that, that was the point, you encounter too many issues and limitations of it simplistic design when you try to build something more powerful

[solowdev]

Don't get me wrong I agree with this!

The point behind my argument was also more "Is it really that much of a dealbreaker for a terminal emulator configuration?". It seems a bit overkill to me in that particular use case. 99% of people will probably be just fine with Lua on Wezterm. It's easy to understand as well as easy to share. And usually, you're not fiddling with your config every morning. You put a bit of work into it, find something that's good to you and then you just use the software.

I'd also mention that even if by example you can do awesome things in Roblox, game devs on Roblox Studio are absolute masochists in the first place lol. (not to mention the predatory 75% revenue cut but that's something else)

[eugenesvk]

(yes, it's not a dealbreaker)

You put a bit of work into it, find something that's good to you and then you just use the software.

Not really, you don't have the perfect design at the start, what usually happens is what I've mentioned in the original comment:

It's especially bad when you want to tweak a thing or two in your config after a while and have to relearn all the lua language design issues again

But even at this initial stage, the less ergonomic the language is, the less likely it is that the marginal user will use it and implement (and then share) his customization improvements, so that means we are less likely to benefit from that

[AndydeCleyre]

I'll just add that Wezterm has so many cool abilities . . . that I use tmux for. So I worry about the complexity becoming a maintenance burden. But you know, so far so good. Wez continues to be excellent at both the development and open discussion for this project. 🙏🏼

[NonlinearFruit]

I agree but also someday supporting Control Mode would be awesome (#336)

[lost22git]

Probably because the stability under windows is not as good as windows terminal, wzt can easily crash the shell ;-)

[Destroy666x]

I have 0 clue where that's coming from... To me this take is pure nonsense. WezTerm on Windows - 0 issues. Well, one small issue - it closes when graphic drivers get updated, but that's nothing. Other than that, I never encountered a serious bug. While with Windows Terminal I get bugs every 5th action or so, e.g. it often randomly spawns 2 windows instead of 1 - that terminal is extremely overrated and overpromoted. Even outdated ConEmu/Cmder perform better, IMO.

WezTerm is the closest Linux experience on Windows, comparable to tmux and other commonly used terminal apps. If it got the missing feature of session management and maybe some more scritable events, it'd be perfect for me.

[kilbyjmichael]

I have quite a few issues on some windows machines but not all. My work laptop shows graphical bugs and crashes wezterm daily but at home it has less issues with that. On linux it does not seem to have any of these issues.

[aj3423]

Currently, to copy all text:

1. enter copy mode
2. g -> V -> G -> y

That's a lot of key strokes, in my workflow I need to do this a lot. It would be nice if there is a built-in "copy all" feature.

[bew]

If you want to copy everything in a single keybind you can probably do it yourself using:

• https://wezfurlong.org/wezterm/config/lua/wezterm/action_callback.html
• https://wezfurlong.org/wezterm/config/lua/pane/get_lines_as_text.html
• https://wezfurlong.org/wezterm/config/lua/window/copy_to_clipboard.html

[aj3423]

Thanks. Now I understand why it uses lua as configuration file, which indeed makes it the best, this is my script for "copy all":

		{
			key = 'c',
			mods = 'CTRL|SHIFT',
			action = wezterm.action_callback(function(win, pane)
				local lines = pane:get_lines_as_text(1000000) -- same as `scrollback_lines`
				win:copy_to_clipboard(lines, 'Clipboard')
			end),
		},

[eugenesvk]

I don't think you need to have constats that match the scrollback, you can also get that info from the get_dimensions

local function copyAll(win,pane)  -- copy all text in a pane (except for bottom prompt in Xonsh)
  local prompt_bottom_offset = 0
  local proc = pane:get_foreground_process_info()
  local name, binpath, arg = proc.name,proc.executable,proc.argv
  local isXonsh = sh.isXonsh(arg)
  if isXonsh then
    if os.getenv("BOTTOM_TOOLBAR") then
      prompt_bottom_offset = 2 -- exclude the main + bottom prompts
    else
      prompt_bottom_offset = 1 -- exclude the main          prompt
  end end

  local dims = pane:get_dimensions()
  local txt  = pane:get_text_from_region(0
    , dims.scrollback_top              , 0
    , dims.scrollback_top + dims.scrollback_rows - prompt_bottom_offset)
  win:copy_to_clipboard(txt:match('^%s*(.-)%s*$')) -- trim leading and trailing whitespace
end

[AndrewSav]

Agree with the following points raised above:

• lua is neither here not there:
  • on one hand the configuration language is difficult to script, yaml/json/toml etc would be preferable
  • on the other hand as a programming language lua is severely limited, wasm would be preferable here because you can compile almost anything into wasm
• This is a programmer's terminal, not a end user's terminal. If you are not prepared to invest hours in configuring it (and enjoy the process), it is probably not for you. In particular:
  • Default key bindings do not make much sense out-of-the-box
  • I doubt that unconfigured configuration defaults are suitable for many people, they were not for me
  • Configuring requires usage of a programming language and understand programming model (event, objects, etc)
  • Because of that, sometimes just copied two (seemingly unrelated) configuration pieces from the documentation to your config can lead to unexpected results. Programmers deal with this every day, a regular user, very likely won't be able to make do without assistance

I'll add one from myself: wezterm cannot do broadcasting and it is not going to be added. If you need broadcasting, it's a total dealbreaker, you just don't use wezterm and use a terminal that can.

I think that the original question trying to address why wezterm is not more popular. For me the answer is clear: it's a brilliant tool, but you need to spend time to learn and maintain it, something that most people would not be willing to. Therefore it is niche,

I doubt very much that wezterm becoming very popular tool is a goal for the author, so because of this it will probably never be. If it was a goal, improvements could be made:

• Lua has to go. Seriously. One does not have to learn the internal eventing system and object model to configure a god damn terminal
• Documentation should be written with non-programmers in mind. Currently it does not even explain what multiplexing is, or why would we need domains, it's assuming, that it's obvious
• Work needs to be done on sane defaults that are usable out of the box
• UI / Features need to be more discoverable. (E.g the program needs a way to guide you to Ctrl-Shift-P, similar to how Windows Terminal does that)
• We need a primer that can help answer questions like "I currently do this in tmux, how can I do this same things in wezterm?"

[Destroy666x]

You are not wrong most of the time in your comment, but:

• "Lua has to go" is nonsense. It doesn't have to go to simplify anything... The entire purpose of Lua is to provide scriptability as an addition to basic functionality. Optional scriptability. You can just add some missing features that have to be scripted now and move configs to a more config-appriopriate format, such as YAML. That's it. You really don't have to burn the whole forest down to eliminate a wolves eating your chickens kind of problem. A beyond terrible solution that alone is good reason to downvote this.
• Defaults are sane 95+% of time. Examples of bad ones would be welcome.
• You mention that multiplexing needs to be explained to newer users, yet in the same list you include explaining stuff to tmux users, which are the opposite. Tmux is I'd say harder to master than WezTerm, which is not suprising considering it's coming from Linux poweruser background. So unless you want 2 documentations or just a subpage like "Hints for tmux users", this isn't really doable without a mess IMO.

[pkazmier]

For me, Lua is a huge selling point. I'm able to do cool stuff like #5435.

[LeoGitHuber]

My Wayland compositor is Hyprland latest version. Wezterm on my system compared to Alacritty is noticeably less performant. When I'm typing, I can feel kind of lag. So I decided to keep using Alacritty.

[xymeng16]

Do you enable webgpu? I was feeling laggy in WezTerm before enabling it but after that it has been working smoothly.

[Ilirski]

@xymeng16 Might be a Hyprland thing. For me, even with WebGpu enabled (and running on Wayland), there is noticeable lag when terminal scrolls when searching for text on Neovim.

[mishurov]

My Wayland compositor is Sway Debian Stable version. I wait for right-click context menu and selecting items with mouse, without that feature Foot can do everything I need and is in the official repository. So I decided to keep using Foot.

[quadespresso]

I'm having another go trying to get back into Wezterm. I'm presently using Terminator, and had previously used Tilix. I would probably still be using Tilix, save for one annoying bug: URL's beyond a certain length (FQDN) become unclickable.

Several months ago, I started down the path of trying to customise Wezterm; I managed to somehow b0rk it in such a way that required me to use another terminal program to revert the config change. I didn't think I had done anything particularly wicked, as I was trying to ease into things.

I came to realise that any modest customisation would result in a side quest to learn. Conversely, any extended period of satisfaction would lead to losing any familiarity I once had.

Fwiw, I have extensive use with iTerm on the Mac. Although one could make the argument that the config isn't as powerful as Wezterm due to the use of Lua in the latter, I've managed to customise my iTerm setup in rather pleasing ways. I don't recall whether Wezterm can do this, but I had configured iTerm to restart/recover (eg, after a reboot) from the last known window/tab/pane layout.

I say that I'm having another go getting into Wezterm. But the truth of the matter is, I've got things to do. Any digging that starts to look like it's turning into a side quest will discourage me from digging further. Perhaps the answer for me personally is to just leave it be and focus on expanding familiarity, customisation of tmux.

[axelhj]

Hi,

I started using Wezterm around a month ago. I like that it is customizable, performant (I use it on Windows) and works well with Neovim.

What I don't like:

• No "officially sanctioned" or at least documented means of handling plugins. Although there are plugins; they are cloned into $XDG_CONFIG_HOME/wezterm and can be required from lua.
• A "need" for plugins since I had some specific keymapping requirements in order to get Neovim work as in Nvy or Neovide. I would like to be able to write a plugin-spec in my .wezterm.lua or a separate file and have it be automatically cloned & updated from inside Wezterm.
• No built-in means of detecting if the foreground pane is executing in the alternative terminal mode. This makes a big difference when binding mouse actions & in particular mouse scroll. I was able to make it work for me though.

Why I think this is not really a problem/turndown for Wezterm:

• It is easy to copy lua code into the config file and code examples are available.
• I think plugin-management by-spec (I am thinking in Lazy.nvim-terms) can be accomplished creating a script that forks/subshells out to git to clone & reset the git HEAD for updating plugins. Plugins can be initialized by setting up a convetion (always cloning into specific directory and having Lua require specific folders and possibly exporting a setup-function through convention (would enable delayed "plugin" loading).

Regards

[quadespresso]

When I was dabbling with Wezterm, I discovered that a misconfigured config file would force me to use some other terminal to recover.

I can't speak for all others, but Alacritty simply complains about the misconfig, referencing the approximate place in the file where the misconfig was found. Granted, it's possible I just haven't managed to craft a sufficiently janky config file for it to stumble over.

[axelhj]

That's interesting. I found that the config auto-reload and error messages was particularly good with Wezterm (compared with configuring Neovim).

But I didn't try reopening with a borked config file. I did need to open Wezterm in Wezterm (or any terminal) to see errors in custom event handlers though, in order to debug my Lua scripts (maybe this goes for any runtime errors/non startup errors). Still, I'm quite pleased with Wezterm overall. I will need to try out Alacritty at some point to compare performance though.

[git001]

As I have used several terminal emulation like wez.
I have to switch to wez because of that issue https://bugs.kde.org/show_bug.cgi?id=482628 in konsole.

wez looks nice for now but a "simple task" like "set geometry height X width (170 x 40)" is very difficult because it's not clear to me is it window/pane/frame/screen/???

I have seen https://wezfurlong.org/wezterm/config/lua/window/set_position.html but this is for position in the Desktop.

Maybe I can tell wez to save the current size when I close the terminal?

Maybe there is a snipplet collection, which I haven't seen yet, which shows how to configure such simple parts in wez?

[git001]

I have found the solution for my question.

Here the config snipplet which works for me.

-- Pull in the wezterm API
local wezterm = require 'wezterm'

-- This will hold the configuration.
local config = {}
if wezterm.config_builder then
  config = wezterm.config_builder()
end

config.initial_rows=25
config.initial_cols=170

-- and finally, return the configuration to wezterm
return config

[axelhj]

I have a similar sentiment, I set it up to remember the width, height and text size and make it configurable with Ctrl+ScrollWheel. After restarting WezTerm the custom setting is saved. I spent around 5 - 10 hours to adapt a config example to my workflow with Neovim. It was quite fun! The code is in my neovimconfig repo for anyone interested.

[akthe-at]

Here is a snippet I have in my config that sets the window position and the size of the screen when I launch wezterm. I also included a snippet that is commented out to launch it maximized...

local wezterm = require "wezterm"
local mux = wezterm.mux
local config = {}

wezterm.on("gui-startup", function(cmd)
  local screen = wezterm.gui.screens().active
  local tab, pane, window = mux.spawn_window(cmd or {})
  -- window:gui_window():maximize() -- maximizes the window at startup but I don't currently use this.
  local gui = window:gui_window()
  local width = 0.95 * screen.width
  local height = 0.90 * screen.height
  gui:set_inner_size(width, height)
  gui:set_position((screen.width - width) / 2, (screen.height - height) / 2)
end)

return config

[btegs]

When I am using LazyVim with Neovim's Catppuccin color scheme, Alacritty seems to render the colorscheme a little nicer. Colors seem to match better and the font rendering is smoother.

I'm a big fan of using Pop!_OS on my Linux machine and the upcoming COSMIC desktop will ship with cosmic-term which uses Alacritty as the backend: https://github.com/pop-os/cosmic-term