Getting into ELPA/core

[leungbk]

Is there still interest in getting this into ELPA or possibly core Emacs? The first issue here was about this very topic, but I'm not aware of any subsequent attempt to enforce the FSF copyright stuff.

[Sbozzolo]

The following is completely my personal opinion.

I think that vterm is the closest thing that the Emacs ecosystem has to a real terminal, thus, the package has a very significant impact on the workflow of specific kinds of users. With enough work to vterm, I think that in the future there will be very few reasons to use alternatives like ansi-term. Emacs deserves to have a good terminal emulator built-in, so I personally would like to stay as close as possible to being able to merge to master (and eventually do so). However, at the moment, I feel the way vterm is implemented is light years away from anything that would be considerable for submission. In my opinion, vterm requires extensive and dramatic refactoring to make the code comprehensible to potential reviewers, maintainers, and those that wish to extend vterm. Not to mention a massive improvement in the documentation and explanation of the package inner workings. Given that I expect a significant portion of the code to change (which will likely remove several copyrighted contributions) and that there are only few big contributors, I haven't insisted on any copyright assignment yet.

It was my intention to undertake the aforementioned structural improvements. (Note that this is not an easy task as it requires deep understanding of a rather complex (and underdocumented) package.) Then, COVID hit I started spending 100% of my life in front of a screen. This, and other pandemic-related stresses, and I couldn't find the energy to do any real work on vterm (thanks @jixiuf for taking care of vterm!), which is why currently there's no sign of going towards a vterm that would be worth submitting to Emacs. (Unfortunately, I don't see the situation improving in the near future)

Again, this is completely my personal take on the issue.

[leungbk]

Thanks for your response. Hope you're doing well in these tough times.

[tpapp]

What would be the advantage of having this package in ELPA/core?

My perception is that it would just add bureaucratic overhead (cf #1) and imply less frequent releases (in core, where modules go to die).

[leungbk]

What would be the advantage of having this package in ELPA/core?

1. People would be free to write other core features that depend on this package. One useful feature of the Debug Adapter Protocol is the RunInTerminal request, which obviously requires a terminal. term and ansi-term seem a bit too slow and buggy to offer consistent support for this, so any DAP client that makes it upstream would prefer to have something like a vterm available.
2. More advertisement. I have no problem using MELPA, but some people don't know about it or deliberately avoid it.
3. The Emacs regulars, who are putatively among the best Emacs Lisp programmers in the world, will have reviewed it and offered suggestions.

My perception is that it would just add bureaucratic overhead (cf #1) and imply less frequent releases (in core, where modules go to die).

It's definitely somewhat annoying. But libraries like xref and seq do just fine being hosted in core while also pushing releases to ELPA independently of core Emacs' update schedule. The ivy family of packages is also on ELPA, but is among the most popular tools around for Emacs.

[pataquets]

See also #237