Towards a (more) stable release of `emacs-libvterm`

[Sbozzolo]

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.

[alphapapa]

@Sbozzolo Excellent, thanks for taking the lead on this. If I may make a suggestion:

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.

I think this should be your first priority, to either get those copyright assignments or replace the code that lacks them. I think your ultimate goal should be to upstream this into Emacs, and any delay in solving this issue (and every commit that doesn't have assignment on-file) makes it harder to achieve.

[brotzeit]

@Sbozzolo Great initiative. I started porting emacs-libvterm some time ago for remacs, because I think the whole FSF stuff is counterproductive in terms of pushing emacs forward. I also think that emacs would benefit if it would be developed on github or gitlab.

I really appreciate the work of the emacs core devs, but the whole mailing list thing will slow down the progress even more in the future. I hope you will succeed with your plans to integrate this package into emacs, but I just want to mention that this package could be a good starting point to go another direction.

I know this is an unpopular opinion, but IMO we all know that the current situation is less than ideal. I doubt neovim would be such a success if it would be developed under the same circumstances as emacs. Just a thought. Thanks for working on this package!

[hexmode]

@brotzeit

the whole mailing list thing will slow down the progress even more in the future

Could you offer a url (perhaps comment on this reddit thread) that clarifies what you mean by this? I ask for a url because I don't want to derail the discussion here more than it already is.

[ferfebles]

In my opinion, more comprehensive documentation will make more people use this package. So more tests and more developers will join.

By the way, really thanks for this package. Now I only miss a web browser inside emacs.

[azzamsa]

@Sbozzolo maybe pin the issue?

[GregorZattler]

@brotzeit: Your arguments are all about the GNU Emacs development.

org mode and tramp are both integrated into GNU Emacs core. Both packages development is AFAIK in no way hindered by GNU Emacs development. Latest versions are available on GNU ELPA. But it brings the additional workload of merging back (in the case of org mode).

[Sbozzolo]

When I opened this issue, at the beginning on 2020, the world was a different place. At the time, I was doing my best to help out with the development and the maintenance of vterm, and I had ambitious plans. The pandemic hit, and, after a while, I felt I had to heavily decrease my involvement in vterm to preserve my own mental sanity. Unfortunately, I think I am not yet ready to resume working on vterm as much as I would like.

My main goal was to understand vterm and document it along the way. In spite of all the time I spent looking at the package, the details of how things works are still beyond me. Since vterm doesn't have a strong developer, I believe that the lack of technical documentation and clear contributor guidelines are a critical problem that the community (me included) has to solve to ensure a bright future for the project.

With this post, I look for people interested in helping out the project. We can work together to learn how vterm works, document it, and fix bugs.

[phikal]

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.

From what I see, this number has now risen to 25. Are you still interested in adding the package to ELPA, or has that plan been abandoned? If so, would there be any interest to add the package to NonGNU ELPA, down the line?

[bard]

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

Small plug, but director.el might help with this part.

[casch-at]

Otherwise, you should try vterm, as it provides a superior terminal experience in Emacs.

❤️ Outstanding ❤️