wezfurlong

I don't recall where I saw it, but my understanding was that : was in the original spec but one of the early implementors (Konsole?) misread it and used ; and that erroneous form is what took off, and here we are today.

The binary is statically linked and embeds several fonts for a consistent, cross-platform, out of the box experience.

The on-disk size != RAM usage, and on-disk size really doesn't matter on modern systems, unless you're on a very resource constrained system, in which case, you probably don't want a feature-heavy GUI anyway.

wezterm supports the kitty image protocol (as well as sixel and iterm2), and runs on all major platforms.

(disclaimer: I'm the wezterm guy)

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!

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.

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.

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.

Frame pointers make things easier for tools to get backtraces without requiring complex dwarf unwinders. The observability is something I value more than not being able to use that register for other things.

The principal difference between the libphenom event dispatcher and the other event libraries is that libphenom can wakeup and dispatch IO events to any of the IO scheduling threads (no thread affinity).

Contrast with the libevent approach of using an application specific scheme to assign descriptors to an event base associated with a thread (strong thread affinity).

This makes more of a difference if you have chatty protocols and/or long lived sessions and no way to rebalance your fd -> event_base mapping.