Default packages selection


#1

Hi,

I was wondering if, in the future, some third party packages would be included with the default install.

I started using Atom a few days ago and like most new users coming from ST I felt a bit frustrated with minor features missing from the stock version. Good news is for every missing features I found a third party package that filed the gap. But my point is that it’s not giving a good first impression to new users.

I understand this has political and security implications, but I’d like to hear your thoughts on this subject.

Is there any change that popular packages would be merged / officially supported / installed by default? To be specific, I’m thinking about:

  • Autocomplete+
  • Highlight line/selected
  • Minimap / minimap highlight
  • Editorconfig or syntax-settings
  • sublime-tabs
  • Scroll past end
  • Incremental search

Can I create a distribution of Atom?
Package Choosing
#2

It’s not politics or security, it’s speed. The more core packages loaded then the slower Atom will load. Load time is Atom’s most serious problem at the moment.

What we need are curated packages. This has started to happen in node by strongloop. You have curations (“products”) to choose from where each product is Atom bundled with a particular set of packages.

A good curation product will have …

  • efficient coverage of needs with least packages
  • different curations optimized for different workflows
  • curations covering all possible needs where possible
  • no conflicts between packages
  • choose best packages of type (where possible)

Different curators could market their curations and gain a reputation for picking good packages.

And of course you only need to pick the one closest to your needs so you can finish optimizing it.

The Atom website could have a curations page and a one-click install of a curation.


#3

Let me start with my standard disclaimer: I am not an employee of GitHub nor a member of the Atom team.

With that said, I can’t remember the last editor I used that I didn’t install a bunch of plugins or packages or whatever the system called them. I even added third-party packages to big monster IDEs like Visual Studio and Eclipse. I expect to have to invest time into any editor to get it to work the way I like.

As for the Atom team taking on official support for third-party packages (or even distribution of them as installed by default), I think it would be highly unlikely for the reasons you mentioned. On the other hand, I think that they will continue to improve the base editor to patch over the obvious holes. For example, a big part of why I wrote my tabs-to-spaces package was to provide commands for tabifying or untabifying a file. These commands have been added to Atom proper separately by the Atom team … though the ability to automatically tabify or untabify on save is also provided by my package which has not.


#4

What do you think of publishing curations? This will get the “IT HAS TO BE IN CORE” people off our backs. The real core could be stripped down to the bare bones.

One of the curations would be the default shipped with atom, like now. This would be curated by the core team.

I’d happily work on the atom.io web page to list the curations. It would just mirror the packages page. I would also work on the code for a one-click function that switches curations.


#5

Personally, I too would be concerned about speed as well as the complications of supporting third-party software (if you bundle it you’d have to support it).

If anything, I’d remove a couple from the bundle as it is.
Markdown Preview, for example, is one of the larger ones, both in terms of load time and file size as far as I can see when building Atom, and is not really a standard must-have feature for a majority of users I’d venture to guess.

And there may be other packages which are useful but could feasibly be left to the individual user to decide whether they want to start out with them.
As @leedohm says, most people don’t mind, and actually enjoy, customizing their tools with add-ons just the way they like. I’m sure slimming the bundle down a bit wouldn’t be met with much hostility.

That being said, I would be in favor of a customizable download / build process, in which people can select a number of packages (third-party or not) which they want to include, in addition to the small core feature set that probably shouldn’t be optional for whatever reasons.


#6

That only solves part of the problem. Not knowing which of four packages (that all claim to do the same function) to choose is still a barrier to entry. That is where curators come in. Node/NPM is already facing this problem in spades. They are heading towards curation.

A curator can be as simple as one who says “these are the packages I use” and “this is the type of workflow I use them with”. Then if you are aware of that user’'s reputation you have all you need to have a good curation.


#7

Granted.
Although I think a good voting / star system, in conjunction with a rotating Featured Packages list, all of which is already in use but needs more time to become really useful, can go a long way to identify the right packages to choose.
Curating is probably an option that becomes more beneficial as the shear number of packages and themes becomes impossible to oversee, let alone to try out. I don’t think we’re anywhere near that point yet, though.


#8

Probably. But what If I (or someone like me) implements the infrastructure for publishing curations, picking curations, customizing the curations, and installing them? I am famous for over-running schedules. :smile:

In any case, we have a bit of a chicken/egg thing here. If we make the curation feature available it might speed things up. It is possible that if NPM seriously considered curation from the beginning they would have less of a mess now.

It is possible that curation should be designed into APM from day one to give needed structure to the publishing problem. Packages that make it into the better curations would be accepted faster and would discourage crappy imitations. So the crap problem might be reduced from the beginning.

The crap problem in NPM is due to lack of hand-holding. Curation is a great form of hand-holding.

EDIT: Doing the curation can be hard work but it would be a great way to give back to the community.


#9

The way I handle this is by “starring” packages I find useful. Then when installing on a fresh machine, I run apm stars --install to download all of my standard packages.

You are able to install all the starred packages of a different user, apm has a command for that. In a way, that’s part of the curation feature.

The workflow around this could be better, though:

  • Allow to “star” a package from the editor, currently this only works from the website
  • Allow downloading of starred packages from the editor, instead of only through apm.
  • Allow previewing the starred packages of a user from the editor
  • Allow to install only the missing starred packages. Currently, apm tries to install all of the starred packages, even the ones I already have.

These would get us pretty close to defining a set of default add-on packages.


#10

You can do it from apm also by using the apm star command. But yes, you cannot do it from inside the editor.


#11

Thanks @nwinkler I didn’t know you could install your starred package with apm, that could be a nice way to implement the curation described by @mark_hahn.

Yet I’m not completely convinced by this approach. What I really liked with ST is that both default features and default settings felt instantly great, I only installed a couple of extra plugins after a few days. Personally I would prefer what happened to @leedohm package, I believe trivial features should be merged into core.


#12

Yes, I’m aware of that, but I find it doesn’t really help with the workflow. I’m in the editor, I’ve downloaded a package there, I’ve tried it, I like it, now I want to star it.

Right now I either have to go to the command line or to the package web site, either forces me to leave the editor. Being able to star it from the editor would feel more natural.


#13

I understand and agree, I was mostly correcting so that other people that read this topic don’t get the wrong idea. I’ve had to correct a couple instances where people will read posts that are months old and say things like, “OMG why doesn’t Atom have this feature!” when they don’t realize that the feature has been around for weeks to months … it’s just that the post is stale.

The short version I guess is that I was replying to you, but not for you :wink:


#14

Got it - thanks :smile: