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.
> 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.
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.
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.
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!
... 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.
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.
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.
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.
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.
...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.
> 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.
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/)
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.
> ...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.
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.
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.
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.
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).
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`)
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.
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.
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.
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.
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.
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.
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.
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”.
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 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.
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.
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.
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'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.
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?
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.
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).
> 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 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.
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.