Towards a (more) stable release of `emacs-libvterm` · Issue #237 · akermu/emacs-...

I have used emacs-libvterm for several months and I am very happy with it. This package solves one the biggest problem I had with exwm, which was the poor terminal experience provided by the bundled term, ansi-term, and eshell. I know that many other users share a similar experience and found emacs-libvterm to be transformative in their workflows. emacs-libvterm has the potential to be an important package in the Emacs ecosystem.

So far, emacs-libvterm has been in a very alpha stage and the development process has not been very organized. This issue intends to be an open discussion to identify what are the directions emacs-libvterm should take and the problems that need to be fixed to move from an alpha stage to a more stable beta.

This is what I think we need:

• More robust continuous integration: Before increasing the complexity of the package, we should improve our continuous integration pipelines to make sure that we don't break anything. This is not easy to do for the kind of software emacs-libvterm is, so any help in this direction would be welcomed.
• More comprehensive documentation: I am not even sure if the documentation covers all the features available in the package for the end user, let alone for developers. Also, it is important that we write some paragraphs to address the question "Why should I use emacs-libvterm?".
• Codified development guidelines: How to contribute? How to format the code? How to write documentation? Who reviews PR?
• Better support for Ubuntu: Ubuntu is one of the most common distributions and many bug reports are from Ubuntu's users. We need to improve the way we support this distro.
• FSF copyright assignment: At the moment, the package is small enough that only 7 people would have to fill the copyright assignment forms. If we have any interested in contributing to GNU Emacs core or ELPA we have to do this now.

All of this is my personal opinion and it is not necessarily shared by the other maintainers. I hope that this issue can be a place for a productive discussion that will be beneficial to the future of this package. Input and help are welcome.