Vty 6 released, now with support for Windows!

Announcements
#1

I’m happy to announce the release of vty version 6.0. The highlight of this release is that vty now works on Windows, thanks to hard work by Chris Hackett and Timofey Zakrevskiy! For years, many people in the Haskell community have requested Windows support in vty. Thanks to Chris and Timofey for the time and energy they put into this, and their patience as we worked out an approach! Thanks also to Eric Mertens and Kevin Quick for early feedback on the release.

In this release, the core “vty” package was reorganized so that support for specific platforms now lives in platform-specific packages that need to be used alongside the core “vty” package. This release includes the release of three aditional new packages:

  • vty-unix (Unix terminal support previously provided by “vty”)
  • vty-windows (the Windows backend)
  • vty-crossplatform (for when you want to support both)

The core package still provides all of the important library functionality and is still a necessary dependency. Applications will need to depend on an additional package for the platform that they need to support. When in doubt, use vty-crossplatform!

The release changelog update has a detailed listing of changes as well as instructions for how to update your application to work with Vty 6.

To get help, please open an issue on the Vty repository.

While I’m at it, Brick has been updated to use vty-crossplatform in version 2.0!

Thanks!

33 Likes
#2

This is fantastic, I cannot believe my eyes.

Is there feature parity between vty-unix and vty-windows?

1 Like
#3

In general, not necessarily. But I believe there’s pretty good feature parity at the moment.

4 Likes
#4

Thanks. From a practical point of view, are there any guidelines on what do to or what to avoid to maximise compatibility among platforms? Eg. regarding colours, mouse interface, etc.

Again I am thrilled to see this, a great step forward for Haskell terminal apps.

3 Likes
#5

I haven’t written any documentation about that yet. This is making me think a feature support table for the existing platform libraries would be helpful. But for now, in general, I’d say that anything not behind a mode flag (as in the Vty mode API) should work, and beyond that, it’d be good if application designers account for users with and without features gated by modes (such as mouse support, bracketed paste, etc).

5 Likes
#6

At the moment, as Jonathan said, there is full feature parity - at least in Powershell and ‘Command prompt’ shells.

However, there are some terminal types on Windows such as ConEmu that are not specifically supported - yet.

That is something I hope to address in the near future.

6 Likes
#7

And, for what it’s worth, even in the Unix context, feature parity is a mess and is quite frankly hard to nail down with all of the various terminal emulators supporting various subsets of features. Even for long-established emulators, participation terminfo is very spotty, and terminfo itself as a vehicle for understanding terminal capabilities is, ironically, woefully incomplete…

3 Likes
#8

It depends on the terminal emulator. Windows Terminal is on par with Unix experience, as Chris already said. Other conhost-based emulators like alacritty should be ok-ish. Vty apps in cygwin-based emulators like mobaXterm most probably won’t work at all (a separate vty-cygwin compatibility package might solve the issue, but I did not really look into it).

More exotic emulators like wezterm - I do not know. Experience reports are welcome!

5 Likes
#9

ghcup_windows_brick
ghcup_windows_brick1432×1089 202 KB

Still doing testing…

12 Likes
#10

I think you made me win a bet? I was wondering how long it’d take for you guys to finish 6 months ago, I said 6 months, others suggested 12 months or longer.

Thanks for getting Windows support it; you’ve just made the Haskell ecosystem so much stronger!

2 Likes