Would you like to help with this project?

[Sbozzolo]

Six years ago, in February 2020, I opened issue #237. After realizing that vterm solved one of my main pain points with using Emacs, I began contributing to the project and eventually helping maintain it. Issue #237 was my rough roadmap for moving vterm out of its alpha stage (particularly around internals, robustness, and documentation).

Shortly after I opened #237, the pandemic hit, and I found that I could no longer give vterm the attention it deserves. While vterm has been remarkably stable (I still use it every day), I believe it has a lot of unrealized potential and it pains me to see all the unresolved issues/PRs.

If you have a PR you’d like to see merged, or an issue that’s been bothering you, I’d love to work together and help you get involved in contributing to and maintaining vterm. Ideally, I’m looking for new maintainers who want to help guide the project forward.

If you’re interested, you can find my email address online or attached to some of the commits in this repository. Please feel free to reach out.

Happy Hacking!

[dickmao]

I'll take it over. But I'd want to merge commercial-emacs/emacs-libvterm en masse. It's a big change if you can stomach it.

[eeowaa]

@Sbozzolo I think that Dick Mao is an excellent candidate for project maintainer of emacs-libvterm, considering his demonstrable expertise with performance-critical Emacs internals.

@dickmao I see that your fork implements "sane handling of wrapped lines", which is something I've personally struggled with. Does your fork resolve this outstanding issue? #179 If so, I'm sure that a lot of people would like to see your changes incorporated, and doing so would bolster community confidence in your ability to take on this project.

[milanglacier]

I submitted a PR aiming at the fix for #179.