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)

Thanks for giving it a try! I recently moved house and have limited mental bandwidth while I'm setting up the new place--since I don't want to drop the ball on resolving these, I'd appreciate it if you would file separate GitHub issues for those items you'd like to follow up on so that I can find and work through them as time allows!

1. Tab titles are set using escape sequences, typically OSC 0, 1 or 2. You can find examples for configuring shells to emit those online, for example: https://superuser.com/questions/84710/window-title-in-bash Terminal.app defaults to snooping the local process list to set titles; wezterm doesn't do this as the terminal may not be local (eg: could be remote ssh or multiplexer session) and using escape sequences gives definitive control.

2. I'd love to troubleshoot this with you; please file an issue!

3. There are currently a set of open and related IME/macOS issues at the moment. You may want to try looking at https://wezfurlong.org/wezterm/config/keys.html#macos-left-a... and fiddle with those options, but you may be left disappointed until the root of those issues are resolved!

4. This is a consequence of being a cross platform program rather than a macOS-first application. There isn't a way to keep the GUI running without any Windows today. Perhaps in the future?

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...

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.

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

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

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.

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...

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).

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.

Thanks; good feedback. It's not currently in production at Facebook, but like just about everything we do, we're quickly iterating.

Regarding roadmap, we'll try to keep the issue tracker on Github sync'd up with the broad goals and milestones, and we welcome feedback there too; they're a bit more dynamic and easier to update in real time than the docs and website materials.

All of these are factors in our choice for printf here.

Another fun one: FILE on Solaris can only be used with file descriptors whose value fits in 8 bits due to an astonishing degree of backwards ABI compatibility. Also on Solaris, printf("%s", NULL) -> crash but on other systems will print "(null)".

In our implementation we couldn't solve the frustrating size_t uint64_t stuff without disabling the compile time parameter checking that gcc provides; I value that more than the slight annoyance of PRIu64.

At a high level, they make it easier to write server (or client) software that deals with multiple concurrent connections (such as HTTP server software, or just about any network facing service these days). They do this by abstracting some of the details away so that you can focus on writing your application code; instead you declare callbacks that get invoked when you have data available.

Traditional eventing frameworks focused on non-blocking I/O on a single thread on the basis that you don't need so many resources to scale up to a large number of clients when compared to a simple one-thread-per-client model.

There's lot of good material discussing this at http://www.kegel.com/c10k.html

libphenom is a bit more than just an eventing framework though; we have a number of APIs that help with putting together the whole application. And we blur the lines a bit: we also have thread pooling and dispatch support for cases where your can't build 100% of your application in a non-blocking fashion.

This is the test code referenced by that commit: https://github.com/facebook/libphenom/blob/master/tests/tpoo...

We haven't looked at libdispatch specifically; would welcome your feedback on how we compare.

We hope we do well here; we've had some nice results: https://github.com/facebook/libphenom/commit/c2753c2154a0cff...

I'm not hot for reimplementing printf, but I did need an interface that made it easy to print diagnostics for various objects; rendering them to the stack and then passing them to the underlying printf implementation makes for a lot of boilerplate code.

In addition to reducing boilerplate and aiding portability, having our own printf implementation aids in consistent behavior across platforms, and allows for a deeper integration with our streams and buffers so that we don't need to make a series of clunky calls to measure how much storage is needed before passing the formatted data into the lower layers.

We're a bit faster than libevent in terms of dispatch throughput; some benchmarks in this commit message: https://github.com/facebook/libphenom/commit/41b6106f04fe62c...

The `tests/bench/iopipes.t` "test" allows you to play with some concurrency parameters to try this for yourself on your hardware.

We haven't compared against libev.

We've added some more APIs (buffers and sockets) since those benchmarks were done and we don't have numbers to share around those yet.

One key difference between libevent, libev and libuv is that libphenom is inherently multithreaded in its IO dispatcher and timeout implementation.

If you're dispatching purely CPU bound jobs, we get very close to linear scaling with the number of cores: https://github.com/facebook/libphenom/commit/c2753c2154a0cff...

What would be a good start would be portable and reliable snapshots with differencing managed by the kernel. Some filesystems offer this capability but it is not available to us in this particular circumstance.

Watchman uses inotify under the covers (or kqueue or portfs, depending on the OS) and abstracts the differences away.

For the Facebook www build it is no longer practical to hash every file to see if it changed because there are so many that it is pretty common for the files to have fallen out of the buffer cache. Attempting to hash the files can thus lead to a significant amount of I/O and translates directly to an increased wait time for the user.

In addition, because of the volume of files, it is not feasible for us to statically declare the build dependencies using a traditional Makefile or similar tool; it is crazy to maintain manually and generating the mapping is itself an expensive operation.

We chose to implement this in C because because it gave us tight and deliberate control of the resources and dependencies of the service.