[Feature Request] Support vim-mode-plus and ex-mode as core packages

[woofdunlap]

Have you checked for existing feature requests?

• [X] Completed

Summary

Support vim-mode-plus and ex-mode as core packages.

What benefits does this feature provide?

VIM keybindings and EX mode functions allow for easy transition from Vi to Pulsar. Both are highly downloaded and useful to a large group of people(IMHO).

Any alternatives?

Current packages are working at this moment. ex-mode is currently on the deprecated list. Issue has been created, but no response.

Other examples:

No response

[zhaolinlau]

I have fixed the ex-mode's deprecation problem as you mentioned, do you need me to publish as a forked package?

[confused-Techie]

So while I get wanting to get these moved into core.

It's a hard choice, because these packages are not archived, and have seen activity as recently as 2021.

The Pulsar team has never yet gone ahead and taken a community package and turned it into a core one, although I think the Atom team may have done this once or twice. So it'd be a precarious decision, to take a project, that could still be maintained away from those that created it, and say it's ours now, essentially locking them out of maintenance. So if we did consider doing something like this, it'd need a really good justification for doing so, and likely would also need a passing poll from the Pulsar community.

I'd say if improvements were wanting on the package, the recommended solution beyond a PR would be to fork, and publish the package again. But would love to hear more thoughts on this, and feel free to tell me if I'm off base @pulsar-edit/core

[Daeraxa]

I agree, whilst it is possible to just fork the projects and take them for our own, that doesn't quite sit right with me. It does being up an important question though about what approach we should take if we did want to officially adopt a community package into core.

The other option is that we make a new core package with the same or similar functionality but without just forking the original (benefits being we don't have any 8 year old legacy stuff and we could even engineer Pulsar with additional APIs to provide more functionality).

[zhaolinlau]

So while I get wanting to get these moved into core.

It's a hard choice, because these packages are not archived, and have seen activity as recently as 2021.

The Pulsar team has never yet gone ahead and taken a community package and turned it into a core one, although I think the Atom team may have done this once or twice. So it'd be a precarious decision, to take a project, that could still be maintained away from those that created it, and say it's ours now, essentially locking them out of maintenance. So if we did consider doing something like this, it'd need a really good justification for doing so, and likely would also need a passing poll from the Pulsar community.

I'd say if improvements were wanting on the package, the recommended solution beyond a PR would be to fork, and publish the package again. But would love to hear more thoughts on this, and feel free to tell me if I'm off base @pulsar-edit/core

The last activity for ex-mode is Feb 25, 2019?

[confused-Techie]

The last activity for ex-mode is Feb 25, 2019?

Yes and the last activity for vim-mode-plus was 2021.

But that's not really the point. These package's are not archived, so potentially the maintainer could at any time begin to pick up activity and start working on these again.

Without the packages being archived, or the developer openly saying they've abandoned the project, or it's been announced as being in maintenance mode it becomes hard to justify cutting off that maintainer from maintaining the package they've created.

As with it open, and none of what I mentioned above, it's hard to factually say that the maintainer may not accept a pull request from other contributors.

But really the biggest point comes from the rest of what I've said. Doing this would be the first ever time for Pulsar. And the maintainer could feel cheated that we decided to take all of their hard work, and essentially render it useless, cutting them off from their own package, that they spent the time to create. They aren't asking us to put into core, we would be taking it from them.

And sure, the license of the package may allow this. But to give a real world example of how this feels to me:

Amazon lets a seller on the platform, this seller makes a really good product and sells really well. So amazon then analyzes this product and recreates it, cheaper than the other seller ever code, then selling an exact clone of this item, under the label "Amazon Basics". Now because customers are able to buy this cheaper product and get it faster, even though it's a total rip off from the original, nobody ever buys the original and that seller goes out of business.

I know this isn't exactly the same, but that's how it feels to me. We would be taking the package someone made, putting it into the editor, where now nobody will ever again download the version that was the original, essentially taking advantage of that users work, in a way that they receive zero recognition, or appreciation for.

---

Like @Daeraxa said, if we did consider that we wanted to do something like this, I'd only be on board with creating a similarity functioning package and moving that into core. Rather than actually taking that package and moving it.

[woofdunlap]

If this project felt that a package made sense to bring into the core, a first step would be to see if the owner of the project might not be ok with allowing you to fork or give you the project?

I understand how taking over a project without comment or permission would be bad.

Thank you for your comments and whatever outcome happens. :)

[savetheclocktower]

In my mind, there exists a level in between “abandoned package” and “core package.” It would involve someone forking the package and maintaining it — perhaps under their own name, or perhaps under an org called pulsar-community or something like that.

If I actually used vim-mode-plus, I'd be happy to fork it and publish it under a new name with fixes, much like @Spiker985 has done for x-terminal-reloaded.

When you rely on package foo and its author hasn't updated it in years, I can understand the impulse to transfer the name foo to someone who is willing to maintain it. But the alternative is to create foo-improved or foo-redux or something, assuming that foo is MIT-licensed or equivalent. I know that's annoying because it requires that you make all foo users aware of your foo-improved fork, but it avoids all the pain described above by @confused-Techie.

I think it'd be a good idea to have an FAQ entry or even an entire page that helps people find maintained versions of abandoned community packages.

[mauricioszabo]

Well, I for one am quite interested in trying to keep a fork of vim-mode-plus.

The obvious problem is that vim-mode-plus have about 12,000 LOC - it's about 1/6 of the Pulsar's src directory, so it's huge - I don't feel confident I can handle one more package to be honest.

But I'll keep anyone informed. For now, I think we can add something to a FAQ or some documentation and then close this issue, and as soon as we have more information update the FAQ/Doc and make a post

[confused-Techie]

@savetheclocktower So as part of a way to help keep users informed of new packages that fork off ones that aren't seeing updates, is something I've attempted to tackle, but never really had the chance to do in the wild.

This is actually one of the driving factors for introducing badges. With the idea that we could add a badge recommending installation of one package over the other, purely due to one receiving more recent updates while the original is not.

This is the reason I always tell people that if they fork a package and bring updates to let me know, so that we can let the community know via badges. But so far, I haven't been able to do this. So I do agree, that's part of the problem, but this was my attempt at a solution

[woofdunlap]

Just wondering what the current status is?
I noticed that "busy-signal" got updated with a github install "badge". Will this be the work around for ex-mode(which also has the same deprecation as busy-signal)?

Thank you, Andy

[Daeraxa]

Since the original conversations here we launched the concept of "Pulsar Cooperative" which unfortunately didn't quite get the attention it needed, and I blame myself quite heavily there. We announced it and got it working but never quite made it fully public knowledge and ready for consumption. We wrote a blog post on it here - https://pulsar-edit.dev/blog/20231004-Daeraxa-OctoberUpdate.html#introducing-pulsar-cooperative and the org for it is at https://github.com/pulsar-cooperative.

The gist of it is that it is a place that orphaned packages (and we have a set of requirements for determining it) can become owned by the community rather than by an individual. The reasoning for this is a lot of people often find fixes for packages but they never get implemented and the person with the fix doesn't necessarily feel like taking on the burden of maintenance. This concept of the cooperative is meant to allow people to "collectively own" a package and submit changes to it.

I'm quite keen on getting traction on this again so it might be that we don't support these as core or fork them under the main Pulsar Edit org but we could look at maybe forking them and putting them in the cooperative.

From a user perpective it would be the same as any other installable package.