10 ms·

WezTerm – A GPU-accelerated cross-platform terminal emulator and multiplexer

114 points by signa11 5y ago

smcleod 5y ago
Iterm2 is GPU accelerated if I remember correctly as well isn't it? Seems incredibly fast for everything I throw at it.
- tyingq 5y ago
  Yes, optionally: https://gitlab.com/gnachman/iterm2/-/wikis/Metal-Renderer https://gitlab.com/gnachman/iterm2/-/wikis/Metal-Renderer
  - smcleod 5y ago
    It's just a tick box in the app, I think it's defaulted to on for a few years now
    - tyingq 5y ago
      Yes, I included the link because it has information on options that disable it, like transparent windows, ligatures, etc.
      - smcleod 5y ago
        Don't get me started on ligatures - now they make iterm run like dog! Otherwise I'm quite happy with iterm - but also welcome alternatives (except those ones I've seen based on electron).
varbhat 5y ago
I use https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot
- lambdaba 5y ago
  Same. Mostly because I've read in many places that it is the fastest, despite not being GPU-accelerated. Wonder if someone can chime in and say if it's true. What I want, in order of importance, is good font rendering (Kitty, for instance, doesn't have the best), speed/responsiveness, and maybe Sixel support. Not interested in tabs at all.
- ghubdub 5y ago
  I absolutely adore foot. I find its got all the features I actually want and use and nothing more. Its also easy to build and package. The only problem I have with it is when I'm using xorg I can't have it :(
kzrdude 5y ago
Wezterm seems to have its own take on multiplexing built-in. And it supports terminal graphics (But not both at the same time for the moment).
CyberRabbi 5y ago
> WezTerm is a GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust This is great. I’ve been looking for a GPU-accelerated terminal written in Rust and haven’t been able to find one. Glad to see someone finally wrote one.
- the_gipsy 5y ago
  Alacritty?
  - HamburgerEmoji 5y ago
    I think that was humor, because there seem to be at least three GPU-accelerated terminal emulators written in Rust.
    - fouc 5y ago
      Would be even funnier if there were zero non-GPU-accelerated terminal emulators written in Rust.
    - the_gipsy 5y ago
      Ahh, wooosh!
  - CyberRabbi 5y ago
    Oh nice, thanks! This wasn’t humor, I really was looking for a modern performant terminal written in Rust. I wasn’t aware of Alacritty, I’ll definitely check it out :)
can16358p 5y ago
Serious question: how much does it benefit to accelerate terminal on GPU? Is it really worth the effort?
- petepete 5y ago
  Lots and yes. The effort has already been made, there are lots of very capable and stable GPU accelerated terminal emulators available. The speed boost makes them worth using. If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt.
  - jstimpfle 5y ago
    > If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt. This doesn't sound like a rendering issue, though. Many text editors can't cope with extremely long lines either, terminal-based or not. That happens when they store lines as flat buffers without any algorithmic optimization. GPU has the potential to speed up terminal rendering a little bit, but in the absence of antialiasing (cache glyphs with the right background color) you can probably achieve 60fps on a 4K screen full of glyphs. It's just memcpy(), a 4K screen is about 32MB of data. 32MB * 60 = 1.8GB, today's memory is much faster.
    - vidarh 5y ago
      Yeah, it's not a rendering issue, it's an architectural issue. It's people writing terminals imperatively: Text comes in from the app, and they trigger a set of updates to state ending in rendering the text straight to screen. The first fix is that if you want a maximally responsive terminal you'll want to decouple input process, output processing and rendering into separate threads - this was established already in the 1980's with the Amiga console handling. E.g. any modern terminal that struggles with handles Ctrl+C is an example of why you want this. The second fix is to "render" into a text buffer and have the renderer look at how many lines it has to scroll and rerender each time it starts a rendering pass, blit whatever is still intact, and then render what is left, rather than process character by character. When the producer overwhelms the terminal in that scenario you end up scrolling multiple lines at once. This will be jerky if the rendering is very slow but it'd need to be very slow for it to be noticeable, and even then it's generally much preferable to the terminal lagging behind. And when you then have a process barfing gigabytes of data to the terminal, most text will not be visible more than a frame on a terminal that insists on showing it all, and won't be visible at all on one that updates faster than the frame rate anyway, and the fix above will simply entirely skip rendering most of the text. As long as your terminal can render a page full of text at a high enough frame rate it will be seamless. With respect to the actual rendering, glyph size tends to be small enough that there's not that much to be gained in terms of acceleration other than a rectangular copy to accelerate scrolling, which is mostly relevant when the terminal doesn't handle huge chunks of data being barfed. The main exception being if you use shaders. E.g. on my personal copy of kitty I experimented with a shader to add a "glow" to characters to make it more legible on semi-transparent windows. But I've applied similar hacks to purely CPU-rendered terminals (created "poor mans outlines" by simply rendering the text multiple times at slight offsets with different colours) and good CPU-rendered terminals can do even that more than fast enough.
samwillis 5y ago
This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.
- mattbee 5y ago
  Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my computer, more confident to try things out if I can see my typing updating instantly than 10s or 100s of milliseconds later.
  - samwillis 5y ago
    I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
    - mattbee 5y ago
      A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)
      - mattbee 5y ago
        e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
pradeepchhetri 5y ago
I replaced iTerm with Wezterm 6 months back. It feels lot more lighter and faster. As SRE I need to work a lot on terminal. I tried Alacritty for a while but Alacritty not supporting horizontal and vertical splits was a major setback for me.
- piou314 5y ago
  I moved from alacritty to wezterm for the same reason. While alacritty definitely feels snappier, the features of wezterm more than compensate for me the speed difference.
- Accacin 5y ago
  Honest question, why not just use tmux? It does everything that splits can do.. and more :D
  - kzrdude 5y ago
    Niche feature but tmux doesn't support graphics like unmultiplexed iterm2 or wezterm
    - Accacin 5y ago
      Fair enough, that's good to know.
joshu 5y ago
i've been using wezterm for six months or so as my daily driver on three operating systems and i love it.
codetrotter 5y ago
https://wezfurlong.org/wezterm/config/keys.html https://wezfurlong.org/wezterm/config/keys.html Happy to see that it includes support for clearing scroll back and that the default key binding for that is the same as it is in the Terminal.app that comes with macOS; Super + K. I just might give this Wezterm a go on my own computers. And since Wezterm is cross platform with support for all three computer platforms that I use; macOS, Linux, FreeBSD, I may finally have a coherent terminal emulator on all of these operating systems. Provided that I find it a comfortable application to use :)
- codetrotter 5y ago
  I've tried it a little bit now with a custom config, and have it almost the same way that Terminal.app is on my system now. My configuration for Wezterm at the moment: - I set the color scheme to Afterglow, which is a lot like the default color scheme of Terminal.app. - I downloaded the SF Mono font from https://developer.apple.com/fonts/ https://developer.apple.com/fonts/ so that it is available to Wezterm, and I defined the font size to be the one that I prefer. This is the font that Terminal.app uses by default but I guess in Terminal.app this font is actually bundled inside of the application because the font did not show up in Font Book and Wezterm couldn't find it either until I downloaded it from said link and installed it even though Terminal.app is already using it. - I configured Command + K to clear not just scrollback (Wezterm default), but to also clear the viewport like Terminal.app does. - I turned off tabs. The are only a few things at the moment that I dislike about Wezterm: 1. The title of each window is simply "Wezterm", and tabs provide additional info but since I am not using tabs and the windows still are titled just "Wezterm" I am missing having the title of the Window be set to things like the current working directory and the currently running commands the way that Terminal.app does. 2. https://wezfurlong.org/wezterm/faq.html https://wezfurlong.org/wezterm/faq.html says that WezTerm version 20200620-160318-e00b076c and newer will automatically set $LANG appropriately on macOS, but I am using version 20211205-192649-672c1cc1 installed from homebrew on macOS Monterey 12.0.1, and it is not setting $LANG for me. 3. I am unable to input characters like æ, ø, å the way that I usually do which is Option + ', Option + o, and Option + a respectively on macOS with the macOS input language set to US. I don't know if this is a consequence of $LANG not being set that I mentioned above or if it's due to the application perhaps not using the operating system provided input methods. 4. When I close the last window the application closes, which is counter to how most applications on macOS work by default, and counter to how Terminal.app works by default. I often close terminals including the last terminal and then later like to tab back to Terminal.app and open a new window. With Wezterm I have to relaunch the application before I can open a new window after I have closed the last window. Is there a way to make the Wezterm application stay running on macOS when I close the last window?
gspr 5y ago
Criticism is cheap, so I wanna first say that this looks like good work! I am somewhat put off when people don't list dependencies anywhere, but rather hide them away in some script (or, in this case, scripts + Cargo manifest).
1hackaday 5y ago
Is there a way to use Emacs on Wezterm using all the same keystrokes as Emacs GUI? (e.g., Meta/Control/Shift + Arrows, Control + Backspace, etc.).
rbanffy 5y ago
Whenever I see a terminal emulator, my first question is whether it can do the VT-100 torture test.
- vidarh 5y ago
  As much as I like the idea, I feel it's not very relevant to most peoples use. I'm writing my own editor. A little toy terminal I have sitting around can run it with just support for a handful of escape codes. To see how broken the terminal still was I fired up emacs. It took next to nothing to make emacs work fine (while having TERM set to vt100). I've seen very little software try to use more than a very tiny subset of vt100.
  - rbanffy 5y ago
    > I've seen very little software try to use more than a very tiny subset of vt100. One thing I really love in command-line interfaces is to use the double-wide, double-height characters VT-100 offers. Even xterm supports that. Another thing I'd love to have is smooth scrolling. Physical terminals could do that and, when a fast connection was 2400, it even made sense. In newish terminals, I'd love to have that, with progressive fallbacks to faster scrolling as the terminal backlog fills up. If your ls -l is a few lines short, it just feels nicer.
    - vidarh 5y ago
      Do you have any examples of command line apps that actually uses the double-wide/double-height characters? I'm aware of them, but I don't think I've ever seen it used. I'm always curious to see good uses of terminal capabilities that are under-used. Smooth-scrolling I think is generally ignored because as you can see from this thread people are obsessed with throughput over all else, and assumes the raw rendering is the bottleneck, but in my experience with terminals it rarely is - few terminals are in any way optimised for speed. Elsewhere in this thread I've advocated for a pretty old-school solution to the throughput and responsiveness issue: Decouple IO and rendering into separate threads. The Amiga did that in 1985, and I have no reason to think it was a particular revelation back then - just necessary to produce something that'd become unresponsive too easily. That split then makes it easy to have the renderer batch updates when there is much waiting. E.g. if so much text comes that it'd scroll two lines in a frame there's no reason to scroll one line twice. If more terminals first did that, then the converse of doing what you propose with defaulting to smooth scrolling when there is little in the buffer, and falling back on faster scrolling would also be "trivial": Just peek at the buffer of how many lines of output are waiting, and adjust scroll speed accordingly. The only difficulty, I suspect, would be to find the optimal rate of change to prevent it from looking jerky.
benfrain 5y ago
Any Kitty users tried this? I’ve found Kitty to be exemplary so would be curious if anyone finds this an improvement?
- jasonjayr 5y ago
  I actually went alacratty => wezterm => kitty. I tried and liked wezterm for a while after alacratty, but after some version, it did something that caused all heavy GPU-using programs(like firefox) to slow down severely, or seize up or something, on multiple computers, after running for more than 24-48 hrs. I had been using the default config, except for my preferred font (the VGA font from https://int10h.org/oldschool-pc-fonts/fontlist/ https://int10h.org/oldschool-pc-fonts/fontlist/). I unfortunately did not have the time to bisect the options or figure out what exactly was going on, but switching to kitty, cleared up the issue. I tried looking for a bug reports that matched my symptoms, but found none, and I really did not have the the know-how to diagnose GPU issues, but I'd love to try to help isolate the bug. It honestly felt like a GPU infinite loop, or GPU OOM issue, because the main CPU was idle, but input and redraws on FF would eventually seize up.
  - conaclos 5y ago
    I'm currently using termite. However Termite is no longe rmaintened. I plan to switch to alacratty or kitty. I'm wondering: Why did you choose kitty / wezterm over alacratty?
    - jasonjayr 5y ago
      I started my journey with urxvt, and was seeking better rendering. Alacratty+tmux (with urxvt keybindings) was working well, and I learned to deal with the "auto resize" when moving windows between screens with different DPIs. I tried wezterm from a thread here, and the emoji rendering (a feature I've never relied on before, but nice to have) was better than on alacritty, and stuck with it. Learned to work with it's tabs + extra features, and stuck around for a bit. Liked that I could run the same terminal on Linux + Windows. I liked wezterm, and it's flexibility, but like I mentioned that GPU bug was killer. I'd have love to help diagnose it, but I'm not sure where to begin. Kitty did most of what wezterm did, and I just stuck with it since. The timestamp on my kitty.conf is 2021-09-11, so it looks like that was the last time I had to tweak it after starting to use it, and I'm happy thus far.
ir193 5y ago
I will give Wezterm a try wheb tmux CC mode(show tmux panel as native window) support is done
theobeers 5y ago
I switched from Alacritty to WezTerm a few months ago. I cannot overemphasize what a healthier project/community this is. The developer is surprisingly responsive and seems to be a good guy. Join the Matrix room (linked from the GitHub repo readme) if you have any questions.
- foothall 5y ago
  I don't know anything about Alacritty. What is unhealthy about the project?
  - Deukhoofd 5y ago
    The lead developer responding like this to bug reports is a good indicator. https://github.com/alacritty/alacritty/issues/1561 https://github.com/alacritty/alacritty/issues/1561
    - wdroz 5y ago
      I side with the lead developer. The "reporter" clearly don't use any nuances and think that his opinions are "aligned with the general public".
      - Deukhoofd 5y ago
        "Green should look like green and not yellow by default" is not an entitled opinion, and definitely shouldn't be met with the hostility it was.
        foothall 5y ago
        https://github.com/alacritty/alacritty/issues/1561#issuecomment-422889256 https://github.com/alacritty/alacritty/issues/1561#issuecomm... describes why the maintainer thinks the opinion was entitled. I don't think your description is accurate.
        wdroz 5y ago
bidirectional 5y ago
What font is being used in the screenshot?
- muglug 5y ago
  Operator Mono: https://www.typography.com/fonts/operator/styles/operatormono https://www.typography.com/fonts/operator/styles/operatormon...
d4rkp4ttern 5y ago
Wow… and I thought Iterm(2) is the best terminal on MacOS
atombender 5y ago
Looks promising! It seems fast, and I like the idea of a more stripped-down terminal app. I use iTerm, which simply has too much. That said, it has a long way to go to beat iTerm for me. Seems more like an early alpha than a finished product? For example, out of the box, it does not support European keyboard layouts: * I cannot type "|" because the Alt key doesn't seem to work, not even with "send_composed_key_when_left_alt_is_pressed" enabled. * Similarly, I also cannot use Super+"[" or Super+"]" to switch tabs, because on my keyboard, "[" and "]" are Alt-7 and Alt-8 respectively. * While Cmd+"-" works to reduce the font size, Cmd+"=" does nothing, probably because "=" requires shift on my keyboard. There's no GUI as such. For example, attempting to close a tab brings up a text mode dialog inside the terminal window, which feels strange and antiquated. Same with the find function; the latter is more concerning, since you don't get access to normal UI functions such as like selection. Right-clicking also doesn't bring up the standard macOS context menu.
- ziotom78 5y ago
  > It seems fast I was intrigued by WezTerm, but after a few tests I realized that it was ~3 times slower than Kitty (my current terminal of choice) in printing random stuff on the screen, so I decided to stick with the latter. It is a pity, because I love the way WezTerm can be configured!
merricksb 5y ago
A major discussion about this already in the past year: https://news.ycombinator.com/item?id=26633708 https://news.ycombinator.com/item?id=26633708 (181 points/8 months ago/128 comments)
sgt 5y ago
For interest's sake, I did a "time find /usr" (ran it first once so it's all in memory) in both Terminal.app on the Mac and then in WezTerm Terminal.app: 6.174s Wezterm: 7.150s

114 points by signa11 5y ago

smcleod 5y ago

Iterm2 is GPU accelerated if I remember correctly as well isn't it? Seems incredibly fast for everything I throw at it.

tyingq 5y ago
Yes, optionally: https://gitlab.com/gnachman/iterm2/-/wikis/Metal-Renderer https://gitlab.com/gnachman/iterm2/-/wikis/Metal-Renderer
- smcleod 5y ago
  It's just a tick box in the app, I think it's defaulted to on for a few years now
  - tyingq 5y ago
    Yes, I included the link because it has information on options that disable it, like transparent windows, ligatures, etc.
    - smcleod 5y ago
      Don't get me started on ligatures - now they make iterm run like dog! Otherwise I'm quite happy with iterm - but also welcome alternatives (except those ones I've seen based on electron).

varbhat 5y ago

I use https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot

lambdaba 5y ago
Same. Mostly because I've read in many places that it is the fastest, despite not being GPU-accelerated. Wonder if someone can chime in and say if it's true. What I want, in order of importance, is good font rendering (Kitty, for instance, doesn't have the best), speed/responsiveness, and maybe Sixel support. Not interested in tabs at all.
ghubdub 5y ago
I absolutely adore foot. I find its got all the features I actually want and use and nothing more. Its also easy to build and package. The only problem I have with it is when I'm using xorg I can't have it :(

kzrdude 5y ago

Wezterm seems to have its own take on multiplexing built-in. And it supports terminal graphics (But not both at the same time for the moment).

CyberRabbi 5y ago

> WezTerm is a GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust This is great. I’ve been looking for a GPU-accelerated terminal written in Rust and haven’t been able to find one. Glad to see someone finally wrote one.

the_gipsy 5y ago
Alacritty?
- HamburgerEmoji 5y ago
  I think that was humor, because there seem to be at least three GPU-accelerated terminal emulators written in Rust.
  - fouc 5y ago
    Would be even funnier if there were zero non-GPU-accelerated terminal emulators written in Rust.
  - the_gipsy 5y ago
    Ahh, wooosh!
- CyberRabbi 5y ago
  Oh nice, thanks! This wasn’t humor, I really was looking for a modern performant terminal written in Rust. I wasn’t aware of Alacritty, I’ll definitely check it out :)

can16358p 5y ago

Serious question: how much does it benefit to accelerate terminal on GPU? Is it really worth the effort?

petepete 5y ago
Lots and yes. The effort has already been made, there are lots of very capable and stable GPU accelerated terminal emulators available. The speed boost makes them worth using. If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt.
- jstimpfle 5y ago
  > If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt. This doesn't sound like a rendering issue, though. Many text editors can't cope with extremely long lines either, terminal-based or not. That happens when they store lines as flat buffers without any algorithmic optimization. GPU has the potential to speed up terminal rendering a little bit, but in the absence of antialiasing (cache glyphs with the right background color) you can probably achieve 60fps on a 4K screen full of glyphs. It's just memcpy(), a 4K screen is about 32MB of data. 32MB * 60 = 1.8GB, today's memory is much faster.
  - vidarh 5y ago
    Yeah, it's not a rendering issue, it's an architectural issue. It's people writing terminals imperatively: Text comes in from the app, and they trigger a set of updates to state ending in rendering the text straight to screen. The first fix is that if you want a maximally responsive terminal you'll want to decouple input process, output processing and rendering into separate threads - this was established already in the 1980's with the Amiga console handling. E.g. any modern terminal that struggles with handles Ctrl+C is an example of why you want this. The second fix is to "render" into a text buffer and have the renderer look at how many lines it has to scroll and rerender each time it starts a rendering pass, blit whatever is still intact, and then render what is left, rather than process character by character. When the producer overwhelms the terminal in that scenario you end up scrolling multiple lines at once. This will be jerky if the rendering is very slow but it'd need to be very slow for it to be noticeable, and even then it's generally much preferable to the terminal lagging behind. And when you then have a process barfing gigabytes of data to the terminal, most text will not be visible more than a frame on a terminal that insists on showing it all, and won't be visible at all on one that updates faster than the frame rate anyway, and the fix above will simply entirely skip rendering most of the text. As long as your terminal can render a page full of text at a high enough frame rate it will be seamless. With respect to the actual rendering, glyph size tends to be small enough that there's not that much to be gained in terms of acceleration other than a rectangular copy to accelerate scrolling, which is mostly relevant when the terminal doesn't handle huge chunks of data being barfed. The main exception being if you use shaders. E.g. on my personal copy of kitty I experimented with a shader to add a "glow" to characters to make it more legible on semi-transparent windows. But I've applied similar hacks to purely CPU-rendered terminals (created "poor mans outlines" by simply rendering the text multiple times at slight offsets with different colours) and good CPU-rendered terminals can do even that more than fast enough.

samwillis 5y ago

This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.

mattbee 5y ago
Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my computer, more confident to try things out if I can see my typing updating instantly than 10s or 100s of milliseconds later.
- samwillis 5y ago
  I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
  - mattbee 5y ago
    A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)
    - mattbee 5y ago
      e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.

pradeepchhetri 5y ago

I replaced iTerm with Wezterm 6 months back. It feels lot more lighter and faster. As SRE I need to work a lot on terminal. I tried Alacritty for a while but Alacritty not supporting horizontal and vertical splits was a major setback for me.

piou314 5y ago
I moved from alacritty to wezterm for the same reason. While alacritty definitely feels snappier, the features of wezterm more than compensate for me the speed difference.
Accacin 5y ago
Honest question, why not just use tmux? It does everything that splits can do.. and more :D
- kzrdude 5y ago
  Niche feature but tmux doesn't support graphics like unmultiplexed iterm2 or wezterm
  - Accacin 5y ago
    Fair enough, that's good to know.

joshu 5y ago

i've been using wezterm for six months or so as my daily driver on three operating systems and i love it.

codetrotter 5y ago

https://wezfurlong.org/wezterm/config/keys.html https://wezfurlong.org/wezterm/config/keys.html Happy to see that it includes support for clearing scroll back and that the default key binding for that is the same as it is in the Terminal.app that comes with macOS; Super + K. I just might give this Wezterm a go on my own computers. And since Wezterm is cross platform with support for all three computer platforms that I use; macOS, Linux, FreeBSD, I may finally have a coherent terminal emulator on all of these operating systems. Provided that I find it a comfortable application to use :)

codetrotter 5y ago
I've tried it a little bit now with a custom config, and have it almost the same way that Terminal.app is on my system now. My configuration for Wezterm at the moment: - I set the color scheme to Afterglow, which is a lot like the default color scheme of Terminal.app. - I downloaded the SF Mono font from https://developer.apple.com/fonts/ https://developer.apple.com/fonts/ so that it is available to Wezterm, and I defined the font size to be the one that I prefer. This is the font that Terminal.app uses by default but I guess in Terminal.app this font is actually bundled inside of the application because the font did not show up in Font Book and Wezterm couldn't find it either until I downloaded it from said link and installed it even though Terminal.app is already using it. - I configured Command + K to clear not just scrollback (Wezterm default), but to also clear the viewport like Terminal.app does. - I turned off tabs. The are only a few things at the moment that I dislike about Wezterm: 1. The title of each window is simply "Wezterm", and tabs provide additional info but since I am not using tabs and the windows still are titled just "Wezterm" I am missing having the title of the Window be set to things like the current working directory and the currently running commands the way that Terminal.app does. 2. https://wezfurlong.org/wezterm/faq.html https://wezfurlong.org/wezterm/faq.html says that WezTerm version 20200620-160318-e00b076c and newer will automatically set $LANG appropriately on macOS, but I am using version 20211205-192649-672c1cc1 installed from homebrew on macOS Monterey 12.0.1, and it is not setting $LANG for me. 3. I am unable to input characters like æ, ø, å the way that I usually do which is Option + ', Option + o, and Option + a respectively on macOS with the macOS input language set to US. I don't know if this is a consequence of $LANG not being set that I mentioned above or if it's due to the application perhaps not using the operating system provided input methods. 4. When I close the last window the application closes, which is counter to how most applications on macOS work by default, and counter to how Terminal.app works by default. I often close terminals including the last terminal and then later like to tab back to Terminal.app and open a new window. With Wezterm I have to relaunch the application before I can open a new window after I have closed the last window. Is there a way to make the Wezterm application stay running on macOS when I close the last window?

gspr 5y ago

Criticism is cheap, so I wanna first say that this looks like good work! I am somewhat put off when people don't list dependencies anywhere, but rather hide them away in some script (or, in this case, scripts + Cargo manifest).

1hackaday 5y ago

Is there a way to use Emacs on Wezterm using all the same keystrokes as Emacs GUI? (e.g., Meta/Control/Shift + Arrows, Control + Backspace, etc.).

rbanffy 5y ago

Whenever I see a terminal emulator, my first question is whether it can do the VT-100 torture test.

vidarh 5y ago
As much as I like the idea, I feel it's not very relevant to most peoples use. I'm writing my own editor. A little toy terminal I have sitting around can run it with just support for a handful of escape codes. To see how broken the terminal still was I fired up emacs. It took next to nothing to make emacs work fine (while having TERM set to vt100). I've seen very little software try to use more than a very tiny subset of vt100.
- rbanffy 5y ago
  > I've seen very little software try to use more than a very tiny subset of vt100. One thing I really love in command-line interfaces is to use the double-wide, double-height characters VT-100 offers. Even xterm supports that. Another thing I'd love to have is smooth scrolling. Physical terminals could do that and, when a fast connection was 2400, it even made sense. In newish terminals, I'd love to have that, with progressive fallbacks to faster scrolling as the terminal backlog fills up. If your ls -l is a few lines short, it just feels nicer.
  - vidarh 5y ago
    Do you have any examples of command line apps that actually uses the double-wide/double-height characters? I'm aware of them, but I don't think I've ever seen it used. I'm always curious to see good uses of terminal capabilities that are under-used. Smooth-scrolling I think is generally ignored because as you can see from this thread people are obsessed with throughput over all else, and assumes the raw rendering is the bottleneck, but in my experience with terminals it rarely is - few terminals are in any way optimised for speed. Elsewhere in this thread I've advocated for a pretty old-school solution to the throughput and responsiveness issue: Decouple IO and rendering into separate threads. The Amiga did that in 1985, and I have no reason to think it was a particular revelation back then - just necessary to produce something that'd become unresponsive too easily. That split then makes it easy to have the renderer batch updates when there is much waiting. E.g. if so much text comes that it'd scroll two lines in a frame there's no reason to scroll one line twice. If more terminals first did that, then the converse of doing what you propose with defaulting to smooth scrolling when there is little in the buffer, and falling back on faster scrolling would also be "trivial": Just peek at the buffer of how many lines of output are waiting, and adjust scroll speed accordingly. The only difficulty, I suspect, would be to find the optimal rate of change to prevent it from looking jerky.

benfrain 5y ago

Any Kitty users tried this? I’ve found Kitty to be exemplary so would be curious if anyone finds this an improvement?

jasonjayr 5y ago
I actually went alacratty => wezterm => kitty. I tried and liked wezterm for a while after alacratty, but after some version, it did something that caused all heavy GPU-using programs(like firefox) to slow down severely, or seize up or something, on multiple computers, after running for more than 24-48 hrs. I had been using the default config, except for my preferred font (the VGA font from https://int10h.org/oldschool-pc-fonts/fontlist/ https://int10h.org/oldschool-pc-fonts/fontlist/). I unfortunately did not have the time to bisect the options or figure out what exactly was going on, but switching to kitty, cleared up the issue. I tried looking for a bug reports that matched my symptoms, but found none, and I really did not have the the know-how to diagnose GPU issues, but I'd love to try to help isolate the bug. It honestly felt like a GPU infinite loop, or GPU OOM issue, because the main CPU was idle, but input and redraws on FF would eventually seize up.
- conaclos 5y ago
  I'm currently using termite. However Termite is no longe rmaintened. I plan to switch to alacratty or kitty. I'm wondering: Why did you choose kitty / wezterm over alacratty?
  - jasonjayr 5y ago
    I started my journey with urxvt, and was seeking better rendering. Alacratty+tmux (with urxvt keybindings) was working well, and I learned to deal with the "auto resize" when moving windows between screens with different DPIs. I tried wezterm from a thread here, and the emoji rendering (a feature I've never relied on before, but nice to have) was better than on alacritty, and stuck with it. Learned to work with it's tabs + extra features, and stuck around for a bit. Liked that I could run the same terminal on Linux + Windows. I liked wezterm, and it's flexibility, but like I mentioned that GPU bug was killer. I'd have love to help diagnose it, but I'm not sure where to begin. Kitty did most of what wezterm did, and I just stuck with it since. The timestamp on my kitty.conf is 2021-09-11, so it looks like that was the last time I had to tweak it after starting to use it, and I'm happy thus far.

ir193 5y ago

I will give Wezterm a try wheb tmux CC mode(show tmux panel as native window) support is done

theobeers 5y ago

I switched from Alacritty to WezTerm a few months ago. I cannot overemphasize what a healthier project/community this is. The developer is surprisingly responsive and seems to be a good guy. Join the Matrix room (linked from the GitHub repo readme) if you have any questions.

foothall 5y ago
I don't know anything about Alacritty. What is unhealthy about the project?
- Deukhoofd 5y ago
  The lead developer responding like this to bug reports is a good indicator. https://github.com/alacritty/alacritty/issues/1561 https://github.com/alacritty/alacritty/issues/1561
  - wdroz 5y ago
    I side with the lead developer. The "reporter" clearly don't use any nuances and think that his opinions are "aligned with the general public".
    - Deukhoofd 5y ago
      "Green should look like green and not yellow by default" is not an entitled opinion, and definitely shouldn't be met with the hostility it was.
      - foothall 5y ago
        https://github.com/alacritty/alacritty/issues/1561#issuecomment-422889256 https://github.com/alacritty/alacritty/issues/1561#issuecomm... describes why the maintainer thinks the opinion was entitled. I don't think your description is accurate.
      - wdroz 5y ago

bidirectional 5y ago

What font is being used in the screenshot?

muglug 5y ago
Operator Mono: https://www.typography.com/fonts/operator/styles/operatormono https://www.typography.com/fonts/operator/styles/operatormon...

d4rkp4ttern 5y ago

Wow… and I thought Iterm(2) is the best terminal on MacOS

atombender 5y ago

Looks promising! It seems fast, and I like the idea of a more stripped-down terminal app. I use iTerm, which simply has too much. That said, it has a long way to go to beat iTerm for me. Seems more like an early alpha than a finished product? For example, out of the box, it does not support European keyboard layouts: * I cannot type "|" because the Alt key doesn't seem to work, not even with "send_composed_key_when_left_alt_is_pressed" enabled. * Similarly, I also cannot use Super+"[" or Super+"]" to switch tabs, because on my keyboard, "[" and "]" are Alt-7 and Alt-8 respectively. * While Cmd+"-" works to reduce the font size, Cmd+"=" does nothing, probably because "=" requires shift on my keyboard. There's no GUI as such. For example, attempting to close a tab brings up a text mode dialog inside the terminal window, which feels strange and antiquated. Same with the find function; the latter is more concerning, since you don't get access to normal UI functions such as like selection. Right-clicking also doesn't bring up the standard macOS context menu.

ziotom78 5y ago
> It seems fast I was intrigued by WezTerm, but after a few tests I realized that it was ~3 times slower than Kitty (my current terminal of choice) in printing random stuff on the screen, so I decided to stick with the latter. It is a pity, because I love the way WezTerm can be configured!

merricksb 5y ago

A major discussion about this already in the past year: https://news.ycombinator.com/item?id=26633708 https://news.ycombinator.com/item?id=26633708 (181 points/8 months ago/128 comments)

sgt 5y ago

For interest's sake, I did a "time find /usr" (ran it first once so it's all in memory) in both Terminal.app on the Mac and then in WezTerm Terminal.app: 6.174s Wezterm: 7.150s