Third party plugins and Code

[igordsm]

Problem

There are many plugin requests in the issues tab and most go unanswered due to lack of manpower. Even when someone takes the effort to actually implement them, it might still go nowhere. For instance, take PRs #890 and #894 or #599 : the proponents are (relatively) responsive, the plugins appear to work correctly and the features would make Code more powerful. Another example would be many PRs (#737 , #784 , #783 ) fixing or improving the Vim emulation mode. Since these modifications must be approved by the core team before shipping, some of these PR's sit there for months (years?) without being merged.

Now, let's be clear: I am not blaming elementary's core team. I honestly believe that they are doing their best, but IMHO this is a losing game. Incorporating every plugin in the main repo requires many review rounds by the core team and they are busy enough as it is. This also takes their time from actually improving the core experience we all know and love. So my proposal is to explicitly "allow" third party plugins and publish instructions on how to distribute them. This could make implementing new features and integrations much faster for Code and potentially help building a developer community around it. IMHO this is why VSCode and vim are loved: they allow extending the base editor in powerful ways and have docs explaining how to build and publish extensions.

Proposal

Create a tutorial and a repository code-plugin-example that people could clone and start writing their own plugins. Maybe even add instructions for adding these plugins to AppCenter if they are good enough.

It would be awesome if there also was a Python version. It seems possible since the Python loader for libpeas is enabled, but there are no current examples on how to use it. This might need more investigation, as I was not able to find a gir file for libcodecore.

Prior Art

Both Gedit and Geany support third party plugins and they also use libpeas. In both their wikis there are many links to new and old plugins. Obviously some are very good and others.... aren't. But the point is that people actually write plugins and publish them for other folks to use, and this would be a very desirable situation for elementary's Code.

I was able to turn #890 into a separate repository that works correctly when installed with prefix /usr (see here ) in Elementary 6. I volunteer to transform this into a tutorial and accompanying example repository if the core team agrees with this proposal.

Possible problems

• Supporting plugins built with old APIs might be a problem. Right now this is not a problem since plugins are bundled with the editor. It also seems like the plugin's API has not changed a lot recently, so this might not be a complicated issue.
• With the impending migration to flatpaks, supporting out of tree plugins might take some effort. This thread implies that it might not be much, but I believe it is worth mentioning.

Best regards.

[jeremypw]

You are right that the review process can be slow and uncertain. I would note that even a third-party plugin would need to be carefully reviewed to become a curated app an the AppCenter so I am not sure it would be any quicker even if it were allowed.

I would review the Vim plugin but I am not a Vim user so would prefer to leave it to someone who is. I have reviewed the code of the #890 - awaiting design approval for choice of shortcut.

I'll leave the project leaders to comment on the other issues.

[igordsm]

@jeremypw Just say it again, I really appreciate the work you and the rest of the team are doing. Your reviews in #890 were helpful and I'm learning a lot in my interactions with the elementary team.

That's a fair point about AppCenter, though. I am not familiar with the approval process, so it might not be any faster after all. A lot of people install software from PPAs though, so this could be an option for less polished plugins (or at least ones that are not officially approved). Well, many users of code are developers, so they could even compile and install the plugins on their own.

It does sound like I'm complaining about the speed of the reviews and that my PR wasn't accepted as fast as I would like, so I'll try and rephrase the issue to sound less spoiled.

Problem

Since there is no explicit permission to create out of tree plugins and all of the existing ones live inside code's source, it feels like all plugin development should occur in the main repo. Clearly this improves their quality significantly, as the core team reviews each PR thoroughly in both source code and UX aspects. However, it also means that all plugins must be officially approved, creating a burden on the core team to maintain all accepted plugins. IMO, it is unfair of me to ask the core team to maintain a plugin I wrote and to fix bugs in its code. If I was in their place I would also be very careful with what I would accept into the main repo, so I understand that the review process is inherently slow.

There is also a related problem that may or may not be "on purpose": there are no instructions on how to create plugins (out of tree or not). I can't say if there's a lot of would-be plugin writers just waiting for instructions, but since the possibility isn't declared most wouldn't even know this to be possible.

Proposal

• Create a tutorial for plugin writing and a repository code-plugin-example that people could clone and start writing their own out of tree plugins.
• Create a list of third party plugins in the wiki.
• Allow for some plugins to be bundled with the default install or to appear in AppCenter if their authors work together with the main team. This would look like the current review process for Pull Requests that add or modify a plugin.

[danirabbit]

@igordsm I think the underlying problem is that everybody wants to write code, but only a handful of us are regularly reviewing PRs. If you wanted to help review PRs in Code that would go a long ways to resolving the issue, I think :)

Personally, I feel like anywhere we've implemented a plugin system it has ended up being a mistake. There's usually not really that many people interested in developing plugins and of those folks who are, it's usually preferable that the features be part of the core app. Something we dealt with in the past was the folders sidebar, for example, being 2 or 3 different plugins. When we merged that functionality into the core app, we were able to make it much more feature rich and work together on one much better folder/project manager feature instead of multiple competing and half-complete plugins. This is the state that it seems smart indent is at the moment. We have one indent feature in the app, and 3 separate plugins which are also fighting to manage indentation. We've also seen that users don't typically enable plugins that aren't enabled out of the box, so they just assume those features don't exist. All in all, I don't feel like plugins have been a really great experience, and I think we should move away from them.

That said, I think when we make the move to Flatpak in AppCenter we'll be in a much better position to talk about how to approach 3rd party plugins in a more officially supported way

[snowparrot]

@danrabbit

Thats sad. VS Code does though have a huge community of plugin devs and it is a core feature now. I

ntegrating into appcenter
will have the benefit that you can easily sponsor someone.
So please do it into appcenter instead removing plugins from code.

[igordsm]

@danrabbit Thank you for the detailed response. It does make sense that most users do not activate plugins that are not activated by default, although it looks like a chicken-egg problem to me. Plugins are kind of hidden, they are not advertised and there aren't many of them.

The point of waiting for flatpak support is being able to clearly separate a plugin from the default install? Perhaps even with permissions specific for each plugin?

Regarding reviewing PRs, I can help with that given some instructions on how to proceed. I'm not great at vala or design but I'll help if I can.

best regards.

[chances]

At the very least, I think it would be beneficial to include instructions in the project's readme describing how to best install a third-party plugin, even if it's built from source on our own.

I like @igordsm's suggestion for a code-plugin-example reference.

[jeremypw]

I think it is up to the provider of a third-party plugin to provide appropriate documentation as to its use.

I would note that all but one of the PRs mentioned in the initial issue have now been merged. Well-used plugins are candidates for merging into the main code (see #1151).