I want to discuss the situation of terminal emulator in Neovim.
Currently we are using libvterm, it seems to be a good solution and thanks to @leonerd we had the chance to have this great terminal emulator in our Neovim instances. But like any other piece of software it has some problems. For example it’s not possible to make it pass command sequences to the underlying terminal emulator (reported 6 years ago here :term should forward unknown sequences to host · Issue #4349 · neovim/neovim · GitHub), or there are problems with wrapped lines, etc.
Now the problem is, whenever I tried to find out the issue and provide a pull request or a bug report I noticed I can’t find an easy way to contribute. “Easy” is indeed a relative word, and something that is easy for me may be hard for another person, but overall I think developers these days can contribute to projects served on GitHub/GitLab “easier” than projects on bazaar served on Launchpad. I think it somehow discourages many to contribute. I always thought about Launchpad as somewhere to serve projects written specifically for Ubuntu.
Neovim was branched from Vim to address similar patterns (Bram governing the codebase in a way that was not easy for developers to contribute, using mailing lists instead of modern code governance tools, contributing to the idea that he is the BDFL of Vim, etc). Neovim tried to make the project an easy target for contributions (pull requests, discussions, etc). So I think the terminal emulator we are using for Neovim at the moment is not aligned with the core values of the Neovim project and there is room for improvement so that we can attract more contribution.
Please let me know if it has been already discussed and maybe I’m not aware of some aspects of this issue but based on what I know at the moment (again, please help me if I need to learn more) I think we should ask @leonerd to migrate libvterm to GitHub/GitLab so that everyone can contribute and easily report and track issues, etc.
Pretty sure that one is handled now. I added hooks for that years ago now. If there’s something still missing there, let me know - but the reason I haven’t looked into it is because I thought it was all being handled now.
Regarding the main concern of this topic, do you find the idea of others collaborating with you to fix issues/develop features interesting? Is it already happening? If not I think moving the project to GitHub will probably make it easier for others to contribute to the project.
Bug reports and feature requests can be sent to any of the above resources.
New features, bug patches, etc… should in the first instance be discussed via
any of the resources listed above, before starting work on the actual code.
There may be future plans or development already in-progress that could be
affected so it is better to discuss the ideas first before starting work
actually writing any code.
(Ooh oops, I should fix the freenode link to point to libera since the network was renamed a while ago).
People do email me and work on things. People turn up and talk on IRC. I usually find these quite constructive as things actually get done in the right direction.
The main problem I find with posting code on github and “inviting” PRs is that people write code first then ask questions later. That’s the wrong order to approach things in, but github seems to actively encourage that direction of working, to the point of severely discouraging any other approach.
I would verymuch like more people to help write code, yes. I’d like them to first talk to me, and we can discuss what needs doing - and most importantly how. Once that is done then code can be written as the second step. Not the first.
Thanks! Now I understand why you chose this approach. I’m thinking maybe we can have a GitHub page solely for bug tracking purpose. While GitHub may not be good for libvterm as it suggests “first write code then discuss” approach, but it’s still a very good issue tracker. Other projects can easily reference issues in libvterm, and everything will be recorded in the issue, etc. I think it helps with organization of issue tracking for libvterm as well as other projects depending on it.
So as an example, if we were tracking issues of libvterm in GitHub, people would create an issue in libvterm page after discussing passing unknown sequences to underlying terminal issue in Neovim’s page and it would be immediately clear for everyone that the issue is pending a libvterm feature. Then someone (probably yourself) would comment on the issue in libvterm stating it is already implemented and closing the issue after reaching to a conclusion with the reporter and it would immediately make it clear for everyone that the issue is not pending libvterm.
Irrelevant with the suggestion above, regarding the GitHub problem of suggesting “code before discussing first” we can write it on top of README.md that this repository because of its nature or whatever requires you to first discuss a feature in IRC or a GitHub issue, etc before writing code. This way more people can contribute and even if contribution to code is not increased, maybe we can have some contribution for documentation and similar stuff.
Just some ideas. I’m sure you already thought about these things and know better what works best for libvterm. I just thought it would be constructive to talk about it.
I suspect you might be over-estimating the amount of people who actually know+care about some bug or feature to actually report it. Of the bugs in the list already, almost all of them are TODO notes written by me, or “it doesn’t compile on my OS” bugs reported by other people, without any suggestion on how to fix it. In the 15 or so years I’ve been maintaining the library, I’ve usually found that people from neovim are easily enough able to poke me about issues. Almost nobody/nothing else actually uses the library.
Sorry, I wasn’t getting notifications from discourse and I thought your previous comment were the final.
As far as I know other than Neovim, Vim and Emacs are also using libvterm.
People do not report bugs and contribute because they don’t know how. I guess many people think libvterm is just part of Neovim and report everything in Neovim’s GitHub.
Based on your comment in Element I’m under the impression that you are not against the idea of creating a GitHub repository. Would you mind if I create one and make you the admin?
