Hacker News new | past | comments | ask | show | jobs | submit login
Wezterm – A GPU-accelerated cross-platform terminal emulator and multiplexer (github.com/wez)
181 points by yagizdegirmenci 10 days ago | hide | past | favorite | 123 comments

I just saw this and after a quick checkout of the latest release (which is what I can quickly install), I feel a bit disappointed. Here is yet another GPU-accelerated terminal that claims to be a VT500 (judging by its Device Attributes report), sets TERM to xterm-256color, while having holes in basic VT100 support (just ran VTTEST in it and saw glaring issues, need not look further than basic VT100 tests, TAB setting/resetting, cursor save/restore).

Please note that I am not attacking wezterm here, my criticism is aimed to be constructive because terminals are important. I think wezterm is a very cool project, and I wish all the best to it, but why not make a terminal that actually (correctly) implements those escape sequences? (We are talking about a couple dozen controls here.) Given the development history (3+ years, 3k+ commits) I would say that this is not a resource issue but a prioritization issue.

For an example of a GPU-accelerated terminal with much less polish, less unicode/ligature support and less portability, but one that takes fundamental correctness very seriously (coupled with excellent performance and very low latency) in a tenth of the source code and (presumably) a mere fraction of development resources spent on it, take a look at zutty. Note, if you like wezterm, you will probably NOT want to switch to zutty, because it's a much more basic program.

Thanks for the feedback. Please keep in mind that this project is a free time project, so when you make a generalization that my priorities are wrong and that I have lots of resources, you're a bit off base.

I've run vttest a few times; one of the biggest issues I have with it is that it isn't a unit test. It relies on a human to know what looks correct and know from what is on the screen what it was trying to do.

If you can concisely describe specific conformance issues, then I'd really appreciate it if you could file a github issue for each one. Please don't just file an issue that says "run vttest", as that isn't very actionable.

I was looking at zutty, mentioned in this thread - and the website says this:

> We have an automated regression testing setup to run VTTEST in Zutty and verify that the output is a pixel-perfect match of the pre-approved video output. You can thus expect the terminal output to be correct – be it driven by tmux, emacs (with org-mode, helm, magit, etc.) or whatever else.

Which sounds like it might be useful for you? https://github.com/tomszilagyi/zutty

Thanks for sharing!

Just before the section you quoted, it says:

> Zutty passes the subset of VTTEST screens that we care about

FWIW, wezterm passes the subset of vttest screens that I care about too :-p

More seriously though, I can't use anything from zutty as it has an incompatible license, and that approach still doesn't resolve the main issue that I have with vttest, which is that it requires a human to interpret the display and reverse engineer what's happening from the code.

esctest is a much more reasonable target for conformance testing: https://gitlab.freedesktop.org/terminal-wg/esctest/-/merge_r...

I get that this is side project that you do in your free time, but expecting reviewers to "file a github issue for each" problem they find in vttest isn't the right answer.

For example, you should maybe open a discussion on what you're seeing in vttest and compare that with OP's comment. If you don't see any problems in vttest, then say so and proceed from there.

So like... open a discussion where they can discuss specific issues? Do you realise how entitled you sound right now?

Maybe I am entitled. But if I posted a comment like OP and got the same response he did, I wouldn't be bothered to file those issues. wezfurlong's response (imo) came across as defensive and dismissive, while also redirecting any potential discussion.

As someone who maintains packages, I'd be willing to hear feedback from any source because being aware of them is better than not at all. I can't speak for how wezfurlong ranks these set of potential issues-- if they're worth even investigating for example-- but from the perspective of a person giving feedback, I would find his response as unmotivating.

I gave it a try and while I haven't noticed any obvious issue, the fact that it offers multiplexing, serial port and builtin ssh support is a bit of a red flag for me. Oh and apparently it embeds lua scripting? Soon it'll have a built-in email client!

In particular I really struggle to understand the point of the ssh interface given that ssh already supports multiplexing built-in with ControlMaster.

What happened to "do one thing and do it well"? Make me an ultra-fast minimalist terminal, then I'll use tmux, ssh and kermit if I need them. Focus on handling all the many, many corner cases that you need to implement for accurate terminal emulation.

Well, I guess I'm turning into a bit of a hater here, I guess I'm just frustrated that it's not the project for me. Hardware accelerated Rust terminal hyped me a little too much I suppose.

You can hate it all you want, I don't mind!

ssh support is present because Windows' pty story, while better than 5 years ago, isn't great. The integrated ssh support allows bypassing that layer when running wezterm on Windows and connecting to a real unix system.

serial port support is present because I do a lot of embedded work on multiple systems and want a consistent environment.

Multiplexing is there because that is actually what you're building when you add multiple tabs, windows and panes.

You can, of course, not use any of those features and still potentially enjoy using the ones that you do need/want. Or just not use it; I don't mind!

zutty is great, and I would use it if it did support double-width characters (needed for CJK, which I need).

Alas, it does not.

I have been able to completely replace tmux with wezterm on Linux and Mac and love it. It even works on Windows and have been able to port tmux bindings . https://github.com/prabirshrestha/dotfiles/blob/master/.conf...

But why would that be beneficial? Having the terminal multiplexer "in th shell" seems so much more convenient. I use Alacritty and tmux but I always open tmux anyway.

the story so far: terminal emulators come and go, tmux stays...

tmux? Most people I know still use screen.

i liked screen until tmux came along. now i had a nice and readable config file and a BSD quality man page.

I feel like I am missing something - does wezterm support functionality equivalent to tmux's sessions? I'm guessing that domains are the wezterm concept but I don't see how to switch or detach from a domain.

... implemented in Rust!!! Having skimmed through quite a few Rust projects on Github lately I am overwhelmed by the amount of code in them. I feel lost looking at any random file, it's too OOP-y for me, I can't really see what it's doing.

I start to feel a little insecure about my own abilities, I've mostly focused on building small components or little systems from the ground (in C) up with minimal or no libraries. That works and is rewarding, until the project becomes unmanageable because of some aspect that I'd done poorly, and I start a new project that focuses on exploring the particular kind of subsystem that I didn't know how to do properly.

It also seems like the following is a pattern. I checked out that intimidating Rust project using git. It's something like 50MB to download. Then I run "cargo build". I wait 5-10 minutes and it is still "fetching". At some point, it goes on to compile 550 (!) transitive dependencies. A little while later, the build failed, could not compile libc, unicode-xid, cfg-if, proc-macro2. Not sure, maybe I have the wrong version of "cargo" installed?

I get back to my small current hobby project, which is somehow more rewarding to me since I can still check it out on a fresh Linux or Windows box, run "build.sh" and run it. That whole process can complete in 20 seconds.

Am I too stubborn? Or should a terminal emulator really be not such a massive project? (No offense meant).

>it's too OOP-y for me, I can't really see what it's doing

Eh, Rust doesn't have OOP. What do you mean? I get that Rust is a bit hard to read if you aren't used to it but apart from that it's fine for me. Don't forget that Rusts verbose-ness also stems from dealing with the borrow-checker which in turn gives you memory safety. Almost every C-project has memory bugs somewhere.

The thing with cargo: In general cargo is really painless, the first build does take long but after that build times are ok for most projects. You only run into problems with projects like servo which are huge.

build.sh scripts have to be managed by the author while cargo run magically works in basically any Rust project.

>Am I too stubborn? Or should a terminal emulator really be not such a massive project? (No offense meant).

Depends, this is not only an emulator but also a multiplexer. A simple terminal emulator that supports basic commands is a small program, I mean look suckless st. But if you get into suporting ligatures, UTF8 etc. you will get a lot more complexity that in turn adds code and dependencies.

I imagine properly supporting UTF8 and Ligatures in C would be a huge pain.

You need the latest stable version of rust/cargo (1.51, released last week) to compile the master version of wezterm iirc

I really wish every rust project had a `rust-toolchain` file checked in[0]. This would cause rustup to automatically select the correct version of rust to use to build the project, thus making it easier to reproduce the build.

[0]: https://rust-lang.github.io/rustup/overrides.html#the-toolch...

Would you like to submit a PR to add a suitable version of that file to wezterm?

FWIW, in my experience so far with wezterm, most people that have run into issues with old rust versions are not running rustup at all, so I feel like something rust/cargo should also have a mechanism to specify an appropriate version.

...does that font used for comments in the screenshot seem like visual terrorism to anyone else? Cursive might be fine on its own, and print is definitely the standard, but haphazardly mixing cursive and print is alarming.

The font's designers did create a video and a page explaining their choices if you're interested. I wouldn't necessarily call it haphazard as it seems there was intention behind the choice to use script for the italics.


Thanks for sharing this!

I don't know if I love it or hate it. It's oddly mesmerizing. Props to them for trying something different.

My wife has a 1950's typewriter with a nearly identical font, and i remember seeing many similar ones over the years.

Perhaps it's just visually jarring to you because it's in phosphor. I wonder if some fonts that look fine on paper don't translate well to computers.

> I wonder if some fonts that look fine on paper don't translate well to computers.

I don't have factual data, but this seems obvious to me. Especially on lower DPI screens. For example, a serif font looks just too busy on a screen, whereas I really love them in a book.

I've noticed that on non high-DPI screens and at "reasonable" sizes (say between 10-14), whenever a font has an elaborate design it tends to be unpleasant on the screen, because everything that doesn't line up with the grid tends to get blurry or have random colors at the edges.

I'm somewhat surprised that bitmap fonts have fallen out of favor. While we may get somewhat used to seeing not perfectly sharp fonts and after a while they don't seem blurry anymore, comparing them side by side with a bitmap font is striking. Especially on dark backgrounds, all the different hues are much more subtle, yet better defined.

I'm running terminus[0] on a computer I sometimes use with a 24" FullHD screen and I find the absolute sharpness of it is very, very pleasant to look at. It is both thin AND without blurriness or color fringes, even on dark backgrounds.


[0] http://terminus-font.sourceforge.net/

I've seen this style used to raise the contrast between comments and otherwise. Though I am surprised it works in Vim given that most terminals can't render multiple fonts at once. Are there control characters for that?

IIRC the monospace font itself would have the cursive characters as its "italic" typeface, then the terminal would just need to be sent the control characters for italic text (i.e. https://rubjo.github.io/victor-mono/)

Oh I see, so it's one font but two styles. That makes more sense (though to be honest I don't think I knew older terminals could do italics either)

It can be tricky to make it work in Vim + Tmux etc., but it can be done provided the font includes it as normal italic typefaces. I use Victor Mono and iirc it's available in two variants depending on whether you want normal italic font or cursive.

I've been using it for a while now, can't say it makes a big difference(both positive or negative), but it kind of looks nice which is the point in the end.

Wezterm can use separate fonts for each style like italic and bold

The script may be the italic glyphs for that font.

> ...does that font used for comments in the screenshot seem like visual terrorism to anyone else? Cursive might be fine on its own, and print is definitely the standard, but haphazardly mixing cursive and print is alarming.

I do it all the time in Vim; it makes it easier to visually ignore comments in the code. For anything that's not a comment, it's pretty ugly.

Seems the intent is to clearly separate commentary from code. I could see that being intentional, imagine cursive annotations on a printed document.

It's not actually cursive though! It's seemingly-random cursive/print mix.

How is cursive for lowercase and normal italic for uppercase random? That said it's a font thing, others may do it more consistently if you're into that.

It's not cursive for lowercase. Look at "which."

The glyphs are just randomly cursive or print. I wasn't complaining about serifs, I was complaining about randomly mixing cursive and print.

That's weird, my complaint is that they don't connect the cursive letters in ligatures

I am mostly feeling sick every time my eyes hit one of those F’s. Otherwise it’s mostly ok.

Oh man I love this color scheme.

How does this differ from other GPU accelerated terminals, i.e. alcritty, Windows Terminal, etc?

For my taste, Wezterm is much more configurable: I can change key bindings, mouse bindings, make custom actions/behaviors, write the config file anyway I want if at the end it generates the needed Lua table,... And it's not gonna stop here. The code is beautifully separated in layers, Rust is used at its best for terminal reading/interpretation..

The codebase is flexible: I could write my own frontend if I wanted or use the termwiz crate (included in the codebase) to build cli apps using the same nice layered architecture..

AFAIK Alacritty is not a multiplexer. Using something like tmux in Alacritty, makes the output slow (because tmux has its own buffer etc). I'm hoping that this doesn't have that issue because it is also a multiplexer.

Another issue I have with Alacritty is that it looks ugly on Wayland (because of lack of user window decoration), I'm not sure if this has somehow solved that issue (building against gnome or something).

I love Alacritty, but for my setup it doesn't work. Looking really hard for a fast and snappy replacement.

Alacritty should support window decorations on wayland. What compositor are you using? Note that alacritty prefers server-side decoration, but some compositors don't implement it like GNOME's mutter[1], in that case it will draw its own decorations.

1: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

I'm using Gnome. And alacritty draws it's own decoration. But they are out of place and more importantly they don't behave like normal windows. For example to maximize a window normally I double click the title-bar but alacritty (I think it's winnit's fault) doesn't react to that. The button placements in the titlebar is also weird and needs me to be really accurate to click the close (x) button.

Yeah, you can blame CSD for that and mutters lack of supporting SSD.

A quick glance at the docs tells me this implements its own multiplexing all the way down, as opposed to integrating with tmux like iterm2 does.

The downside is that this requires installing the multiplexer on the remote machine, whereas iterm works with the much more prevalent tmux install.

Not sure what this means in terms of performance, I've never had any issues running remote tmux in alacritty or in iterm (via `tmux -CC`).

I don't have any use for running tmux locally, but I would sure love to be able to have actual windows for remote sessions (I use i3 and would prefer to manage all windows through that).

FWIW, wezterm is very slowly building support for `tmux -CC` as well: https://github.com/wez/wezterm/issues/336

tmux + alacritty seems perfectly fast for me, tmux's buffering really shouldn't slow anything down

Kitty as well.

Moment of shame. I don't understand terminal multiplexers. I just open a new terminal and SSH in again if need be. Keyboard shortcuts to arrange the windows.

Main feature for me is that I can have a few terminal windows/panes open, close the terminal, and open it back up later to the same tabs and panes still running. Or, I can open a terminal on any virtual desktop and get the same terminal on all of them.

I work with a few different hosts on SSH and having an active connection for each as a labelled window (tab) in the terminal itself that I can just open up a terminal anywhere to come back to is great.

Personally I use the `tmuxinator` helper tool[^1] that allows you to create configurations as json files to be launched/attached to with short aliases (eg `mux s myconfig`)

[1] https://github.com/tmuxinator/tmuxinator

You’re taking advantage of modern UI tools and modern levels of screen resolution and not intentionally recreating the old way of interacting with multiple terminals simultaneously.

Literally no shame in that. GUIs with multiple windows and tabs were invented for a reason.

That's not the benefit of terminal multiplexers people use them for ...

I know dozens of engineers that maximize one single native OS terminal window and use tmux or screen inside of it to divide it into more “windows” (which are not OS native and just basically ascii frames). Yes there are other benefits too, and I use screen for those uses, but that’s not what OP was talking about.

Whilst I use terminal multiplexers daily on localhost, the best feature of a multiplexer is that even if your TCP connection gets broken, chances are that the long-running, business critical command you had to execute on a remote machine will still be running.

You probably should have bg'ed that process, but yes.

Install tmux or screen, use mosh instead of SSH, and login with a ssh key.

The time waste will be paid off by giving yourself a cross-networks, cross-client, always ready, instant on, saved state, scriptable replica of what you're doing on your computer by arranging windows.

I can mosh to my VPS and have tabs and windows and panels left running as I left them. The connection doesn't fall if I change WiFi hotspots or switch to my mobile hotspot. This works on my laptop, desktop, phone, raspberry, whatever the client.

And doesn't require hardware acceleration /s

Highly suggested.

You still want hardware acceleration in whatever you are running tmux in.

Er, I'm in the same boat as the parent. Also wondering what hardware acceleration does for a terminal emulator? Isn't all this just text?

If you don't, you don't need to do real development there.

Or having a persistent state across long times, or work from a specific tty from another host... Or be able to split the screen to follow multiple outputs...

I mean, you can live without, but once you really meet them, you can no more.

Very nice that this supports ligatures which is what I've been missing from alacritty.

Yes, looking like Alacritty is far from supporting it as well [1]. Not that it usually bothers me and I really do not care for ligature-based coding fonts, but it can pop up in e-mails and filenames for things like umlauts.

[1]: https://github.com/alacritty/alacritty/issues/50

No knock on people who spend their time working on Free Software, but I genuinely don't understand why discussion threads turn sour so quickly when it comes to terminal emulators and ligatures. Both in the linked thread and in the case of libvte [1] (a terminal emulator widget used in tons of popular emulators) the maintainers seem to be aggressively against ligatures. It's a shame because I can't find a single terminal emulator on Linux that is as usable as iTerm2, and not having ligatures is the biggest knock against most of them IMO.

1: https://bugzilla.gnome.org/show_bug.cgi?id=584160

Most terminal emulators date back to a time when one byte of input occupied one character-cell on-screen. Since Unicode arrived with combining characters, terminals have adapted to N bytes of input occupying one character-cell, or under special circumstances (Chinese characters, emoji) two character-cells.

Proper ligature support requires terminals to support N bytes of input mapping to M character cells... and unlike the N:1 or N:2 cases, the N:M case doesn't allow a hard-coded list of how many cells an input string covers, it varies from font to font. And that risks software designed for one font breaking in a terminal that uses a different font, if it has a different set of ligatures, or the ligatures are different sizes.

Yeah, this stuff is hard. The approach used in wezterm is to use unicode graphemes for cells, and use the unicode width of the grapheme to decide whether a given cell is double-width.

Ligatures are handled at rendering time, partly because the terminal emulation and model layer doesn't know about fonts (it can run "headless" in a multiplexer where there are no fonts), and partly because the shaper library doesn't output information about cells but rather about which glyphs to render in which positions--that information doesn't easily map to the terminal cell model.

For extra pain, some font designers have ligatured sequences that map to a single glyph that may be several cells wide, while others use alternative glyph fragments for each component of the ligature, and others may emit two blank glyphs, followed by a triple wide glyph with a negative x offset of almost two blank glyphs in width. It's difficult to map this information to cells.

The problem actually existed before Unicode appeared. Terminals which supported Chinese, Japanese, or Korean characters have had to deal with 2 cell wide glyphs, even for text encodings which use 1 byte per glyph.

If you see the term "full width" character in old terminal related specs and documents, they are talking about 2 cell CJK glyphs/characters.

If "usable as iTerm2" means the terminal actually aims to have features, then you can try my project Extraterm ( https://extraterm.org/ ). It supports ligatures and more.

Thanks for the plug! I'll try it out over the weekend. I've held off on using an Electron-based terminal emulator so far because of memory concerns - I usually have tons of terminal windows open, leaving the job of tiling them to i3. But working on a mac with iTerm for work makes me really miss it on my own time, so I guess I'll try extraterm out.

Thanks in advance for trying it out. If you stay using it or not, do create issues on GitHub for missing features or things which could be improved, otherwise I just won't know what people need/want.

I can understand your concerns around resource usage. Extraterm doesn't follow a minimalist philosophy, more of a swiss army chainsaw one. But as an application it still needs to make you think "what I'm getting out of this is worth the resources". Features and new features you can't find else where, plus becoming a platform for plugins and deeper integration with other software is the broad idea here.

Does it support wayland? I don't see this mentioned via a github search.

The underlying stack is Electron. So if Chrome runs on on Wayland, then Extraterm will too.

It wasn't clear it was Electron, which does not work on Wayland.

Umlauts? How come one needs ligatures for umlauts as they are independent characters with own Unicode or even old ASCII set codes[0].

[0] https://resources.german.lsa.umich.edu/schreiben/unicode/

I believe that Unicode has multiple representations for Latin characters with diacritics: ä can be represented as a single character, but it can also be represented as two characters, “a”, plus “add two dots to the previous character”.

You can convert between these forms.

You do not need ligatures for umlauts, but that does not stop the odd software (or maybe user?) here and there refusing to do it the “sensible way”.

Forgive me as it's not my area of expertise, but why does the world even need a GPU-accelerated terminal emulator ?!?

Surely even the worst of the worst motherboard embedded graphics can cope with displaying some text in a window ? Its something computers have managed to do since their invention ?

I would like to know this too. GPU accelerated terminals are growing in number so there must be a use case. I'm an avid terminal user, but I've never discovered this.

Displaying terminal output nowadays is more complex than 30 years ago.

Today you want to be able to render high dpi text on a 4k display, possibly on multiple monitors in multiple terminals at the same time.

And you better have more than 240 FPS (terminal render updates per second), because some displays run at 240hz or higher and you don't want your terminal to produce flicker on your screen.


I'm sorry, what ?!

I use SSH a lot every single day. Not once have I thought "sheesh, this is slow".

Before SSH became the default, I spent even more of my life on Telnet. Same again, never had a problem.

I also sometimes do console connections to switches and routers.

The only lagging I've ever seen in a terminal window is when I've been on the end of a poor internet connection !

And yes I've done it on 4k displays and multiple monitors and multiple terminals.

I've never observed any flicker either (and yes I use non-standard "modern" fonts).

I've never had problems with Microsoft Word or Notepad either !

I'm sorry but I fail to see why a terminal emulator needs the same power as Photoshop or your favourite game.

Frankly I would put a GPU-accelerated terminal emulator in the category of "product solving a problem that doesn't need to be solved".

I'm very sensitive to terminal latency and I find terminals like gnome terminal and the like are simply too slow for me. I use xterm on daily basis because it provides the best latency.


I know it's not an issue for many and they tell you "excuses me, what?", but I can tell you, it's a thing.

Is there a specific scenario where you notice latency?

Yes, always. I can immediately notice the difference when I type on lets a gnome terminal vs. xterm. But it's not only related to terminals. I have the same issue with editors. For example, the Atom editor is unbearable slow, VSCode is slow, Vim with a few plugins (incl. syntax highlighting and the like) is okayish and plain vi is fast. At least that's how I experience it. I decided to go with vim + plugins, because it provides the best tradeoff in terms of features and latency.

Interesting. I've never experienced latency. I use a 2k monitor. I guess the jump from 2k to 4k is big. I use terminals for text editing with vim (my only IDE), and basic command line stuff like grepping logs, dealing with git and such. I've used xterm, rxvt and st.

When I think about it, there's no smooth movements in my usage. Scrolling is at least one line at a time, cursor movement is at least one character width at a time. So I would be hard pressed to notice latency.

Btw, 240 fps is a very minimal jump from 120 fps. It's much less than 60 to 120. I can't imagine ever being able to tell if my terminal is getting drawn faster than ~50 hz. Well maybe if I was scrolling more than 50 lines per second, but I would probably not care how it looks.

I agree 240hz is maybe a bit extreme. But I think that most people could immediately tell the difference between 60hz and 120hz.

> but I would probably not care how it looks.

Me too. It's not about aesthetics, I don't care much about it. It's how it feels, slightly higher latency gives me an uncomfortable feeling during computer interaction.

If I had to decide between something that looks very pleasant, but is slow and something that looks crappy but is ultra fast in terms of latency, then I would always pick the latter.

Okay, so it is used for rendering the text to the display? Do IDE's use hardware acceleration? I'd think it is kinda the same general thing.

- Eventually someone is going to bring back RIP graphics and send GPU commands down a text-terminal pipe, and think they were the first ones to do it.

- Also: only this way can we lay the groundwork to get terminals to look like the hilarious parodies of computer interfaces in movies.

Since it uses its own ssh library I assume it won't support ssh agent/unix socket forwarding this way?

it uses libssh2; agent authentication is supported, but libssh2 doesn't currently support agent forwarding: https://github.com/libssh2/libssh2/issues/535

I see perfect 256colors test results for foreground and background. Very nice, author.

It's working for 24-bit color as well.

I tried it out just as an terminal emulator and it looks quite nice. I noticed that the startup time is a bit high when using appImage - much snapper once you build it from source. Though will continue to use Tilix as it is as snappy (not a multiplexer) + has buttons for vertical/horizontal splitting/tabs.

[0]: https://wezfurlong.org/wezterm/install/source.html

[1]: https://gnunn1.github.io/tilix-web/

Am I the only one who doesn't use terminal multiplexing? I used to use screen back when I would have eternal shells open on remote systems via SSH, but why would I need to do this locally when I have a window manager?

i guess it really depends on how good your WM is. fundamentally it is very easy to recreate a tmux-like workflow in a terminal emulator that has windows and tabs. so why invest the time to learn tmux?

if for nothing else, it's a much nicer nohup(1).

because once i learnt it, it doesnt matter which terminal emulator i use, i have a full window manager solution _anywhere_.

but it's not a zero sum game for me, i have multiple windows to multiple hosts, not one giant tmux mess. in those windows i have tmux'ed sessions, which makes working on a given host much nicer for me.

i set up each of my terminals with a specific purpose. they all live in a different directory and stay there (or switch to subdirectories and back). say for example a terminal for each project i am simultaneously tracking, or each long-term task.

as a result i have dozens of terminals.

but, i never work on more than one project or task at a time. so there is really no need for more than one terminal-window to be on my screen at any one time.

on other words, using tmux locally helps me avoid clutter on my desktop.

I have to say this terminal surprised me. Feels really fast (faster than kitty) and have some features I was missing.

I will give it a fair trial

Faster than Kitty takes some doing, definitely going to give it a try too.

i would not make sweeping statements like that...

here is my non scientific benchmark, latest macos:

new wezterm window: `find /`: 70% CPU

new kitty window: `find /`: 30% CPU

the kitty window is visually faster as well...

Is there benefit from using one of these GPU-accelerated terminal emulators on a laptop with integrated Intel graphics?

I've just tried it on 2014 MacBook Pro with Intel Iris GPU. It seems it bit more sluggish than the built in Terminal app.

No hard numbers, yet simply resizing a window is visibly slow or "accidentally" catting 100k line txt file in the terminal takes several seconds. Both is instant in iTerm and Terminal on my machine.

Isn't Apple's terminal already GPU-rendered too? Or was that iTerm2…

iTerm2 can be (it's configurable). Not sure about Terminal.

Feels snappier than iterm2 and Hyper, the latter supposedly being hardware accelerated through WebGL. Nice!

Hmmm. Sixel graphics support, I see. That’s something I wish was more readily available everywhere.

It renders Pragmata Pro Mono Liga much worse on Linux than Tilix does. Otherwise, I’d give it a shot.

Oo, both X11 and wayland support. Will try.

Wezterm, like Alacritty doesn't support RTL languages.

Could you provide a screenshot of a RTL terminal? I wasn't aware people use those. Probably showing my own ignorance here, but when would you need to use it.

Also, I'd assume this has nothing to do with terminal emulator (might be a wrong assumption). I thought the shell/TUI just has to position the cursor on the right hand side and emit the correct Unicode?

Currently I'm aware of two terminal that support RTL languages, Konsole and gnome-terminal.

The terminal itself doesn't need to be RTL, but the text that is entered or printed.

Here's screenshots of Konsole and Alacritty: https://imgur.com/a/x8Zy6ug

I'm not very knowledgeable on this. But, a program that wants to support RTL languages, in this case a terminal, needs to support bidirectional text and text shaping.

What theme is that?

I don't see it anywhere else on the web so it might be specific to Wezterm, but they seem to call it "Batman".


The terminal theme in that screenshot is the builtin wezterm defaults which are a minor evolution of the "Wez" theme that I uploaded to a random wiki years and years ago, and which found its way into the https://github.com/mbadolato/iTerm2-Color-Schemes collection and is now also available as a selectable theme in wezterm: https://wezfurlong.org/wezterm/colorschemes/w/index.html#wez (that's NOT the same as wezterm's defaults, but it is very similar!)

The colorscheme used in vim in that screenshot is my personal vim colorscheme which is leaning on the terminal color scheme, with the doc comment color explicitly selecting that orange color, for its added visual terror factor. (Really, I just like my Rust doc comments to be rust colored).

If you're looking for the precise colors in wezterm's defaults, they're here: https://github.com/wez/wezterm/blob/main/term/src/color.rs#L...


Why would a terminal app have anything to do with any of that? You don't even mention having uninstalled a program

I think this is a GPT generated text lol

For context this was the original comment:

> No offence, but will installing this on "Windows 10" lead to any instability. Can I uninstall it without breaking something. I ask because, I'm currently on my second desktop. Recently bought after my eight-year old Linux desktop gave up the ghost.

> As I said, I bought a new PC intending to put Linux on it. On the first, trying to enable boot-from-usb, to create a recovery image. Couldn't enter the bios. After enable safe-mode in Windows, I ended up with a black screen. Because certain combinations of graphic card, monitor and UEFI are incompatible. You might think all I need to do is reboot, but no, the recovery utility puts the PC in permanent safe-mode.

> On the second PC, I tried to enable usb boot in the UEFI but ended up with "corrupt bios". So now I don't dare touch it for fear of ending up with a black-box again. How the f*ck can they design a combination of Windows and the BIOS that there is no way of recovering from a bad configuration. I never had such problens on my eight year old PC. There was no way to break the BIOS with a few key combinations. I tried reading-up on UEFI, seems to be an excercise in confusion. Sorry for the rant.

I've been seeing people claim this a lot recently and I rolled my eyes.

But then I saw their latest comment and you're absolutely right ahah. Good call


I agree with you that you should not touch your computer.

What brand of laptop?


I think maybe this might be pretty good evidence that this is gpt3 ^ I've played around quite a bit with gpt3 and it does this sort of thing all the time where it won't actually directly answer a question, kinda skirt around it cause it's a stochastic parrot.

Looks like it cleared all it's comments to lorem ipsum. That's funny

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact