According to this this slideshow:

At a fundamental level, this is the state of terminal emulators today as I saw it. You have fast terminals, feature rich terminals, and native terminals. You can pick at most two properties to have.

Ghostty aims for – and in my opinion already achieves – all properties.

Also, calling out the warning signs, my bar for a native platform experience is that the app feels and acts like a purpose-built native app. I don’t think this bar is unreasonable. For example, I don’t think it’s unreasonable to say that Alacritty is kind of not native because new windows create new processes. Or that Kitty is kind of not native because tabs use a non-native widget. And so on (there are many more examples for each).

Take a look at xtask. It essentially relies on the fact that you can add cargo aliases in local files in order to execute specific packages.

When I create a workspace that has some form of code generation I like to overwrite cargo gen to whatever is doing the generating.

Number 4 is only about not returning impl Into and instead just returning T.

That’s a bummer. I guess what I though was PyO3 type hints was actually just PyCharm guessing at the types.

I tried creating a .pyi file and it seems to be a pretty big improvement over no type hints, but I don’t know how to add type hints for modules added with PyModule::add_module and adding the .pyi file seems to make the type checker not know about my other modules.

Would you mind sharing the script for auto generating type hints? Keeping them in sync manually would be pretty annoying.

How is the quality of the generated bindings?

I have previously used PyO3 for Python bindings and it doesn’t seem to correctly generate type hints.