Well, the title is self-explanatory really…

I love Sublime Text. I’ve been using it for the past 1 year and it’s really the best all-rounder text-editor around.

I just wanted to put this idea out into the wild and see what others think of it (like if it’s worth the “enormous” amount of effort).

Just to be more precise, I’m asking:
What does the Sublime Text community think about adopting a naming convention for packages in Package Control?

From what I see, it makes searching for packages from within Sublime Text easier and, more importantly IMO, adds consistency. But adopting such a change, will require a lot of effort.

Also, while we’re at it, what about restricting Package names from containing “Sublime”, “Subl” etc from their name?

PS: 16 year old on this side…

PPS: A rough idea for a convention…
Names of all packages for:

• languages should start with "Language - " (default packages would be violators)

• color schemes should start with "Color Scheme - "

• themes should start with "Theme - "

• plugins should match the regex “[a-zA-Z][_a-zA-Z0-9]” (be valid Python identifiers, so that someone can just import and do stuff with them, like write a plugin for plugin…)

Package control channel maintainer here. I usually recommend people to follow the “color scheme -” and “theme -” conventions and I will also note if it was better to not use spaces in the package name (in case it is supposed to be included by other plugins). Packages containing the name “sublime” are rejected by default and will only make an appearance if it’s really special to their name (for example, colorsublime which is based on the colorsublime.com website).

I’m not too fond of the language prefix, especially considering that in the default packages it is already used for the dictionary files.

Edit: note that I also accept “… Colorscheme” since there are also a hand full of packages named like that.

So, you’re saying this kind of naming convention is unofficially in place?

Because I remember coming up with this after seeing that it was not the case in every situation. Not on the top of my head when and where though…

Well, I suppose we have the following conventions, although not everyone follows them (since they are only conventions anyway, and not specified anywhere):

• Color Scheme - | Color Scheme
  For color schemes, obviously.

• Theme - | Theme
  For themes, may also contain color schemes

• <language/framework name> Snippets
  Snippets for said language

• <lanuage/framework name> Completions

• <language/framework name> Auto-Completions [or variant]
  When programmatically building completions, based on code and considering local variables etc

Something not covered above, mostly general-purpose plugins not limited to a certain language.

I will most likely mention something like this in the unofficial docs’ “creating packages” guide.

Edit: The god damn and FUCKING ANNYOING spam filter, which is inaccurate as hell, prevented me from posting the entire list. RAGE!

Well, how breaking would it be to change all “*** Color Scheme/Theme” ones to “Color Scheme/Theme - ***”, for consistency purposes.

PS: Sorry for the delays, how exactly do I get notified about posts?

You can’t be notified. It’s not set up.

With the new Forum, it is now!

All themes would break and need to be updated, because they require hard references for icons and other images (afaik).

Color schemes would not need to be updated, but every user that used a color scheme in a renamed package would have to re-set it to the new name.

Those hard references are part of the .sublime-theme file itself. So, changing/updating them is just a job of running a find and replace after renaming.

As for Colour Schemes, it is an issue. A one-time change is more convenient for consistency across the packages. But it’s not a call I’m going to be making.

@jps What do you think?

The issue is that we do not have the power to do so. Only package authors can perform this change, or we would have to do regular expression replacements on all renamed theme files which is something I prefer not to do.

Jon doesn’t need to have a say in this since he is not involved with package control (it’s not even a default package) and this is a package control issue. If you’d want to mention someone, it should be @wbond.

Would be better to only allow valid python identifier as package names. Disallow uppercase letters though, so pretty much [a-z_][a-z0-9_]*.

Don’t use UPPERCASE letters

OS X and Windows have case-insensitive filesystems by default. Users may
mistakenly require files from a gem using uppercase letters which will be
non-portable if they move it to a non-windows or OS X system. While this will
mostly be a newbie mistake we don’t need to be confusing them more than
necessary.

http://guides.rubygems.org/name-your-gem/

With exclusions:

• must not be prefixed with ((subl(ime(_?text)?)?|default|package)_?)
• must not be suffixed with (_?(subl(ime(_?text)?)?|default|package))

Then recommend to append commonly worded packages.

• _colorscheme
• _theme
• _syntax
• _snippets
• _completions
• …

Also would be good push packages one folder deep and require each package to a vendor name. So package names would be {vendor}/{name}: [a-z_][a-z0-9_]*/[a-z_][a-z0-9_]*.

Sounds like a good idea, if this was a comvention from the start.

However, there are two notable problems that will likely prevent this from happening any time soon, if at all:

1. Shipped packages do not follow this convention (e.g. Theme - Default).
2. It is completely unfeasable to force-rename 3400 packages because of the side effects it imposes, which is mainly stuff breaking.

If a naming convention is desired then it should be implemented for new packages sooner rather than later. The more time that passes the bigger the problem is.

Package Control can enforce a convention for all new packages. Providing a step by step guide on how to update a package for older packages. It at least stop the problem from getting larger.

We could indeed enforce conventions on new packages, but I’m afraid of the discrepancy it will impose, because the previous (and current) convention is TitleCasing package names (without spaces), which is the opposite of snake_case.

Additionally those packages including keywords like “theme”, “color scheme”, “snippets” or “completions” usually have those separated with spaces. Those packages don’t include Python plugins to begin with, so it will also never pose an issue for them (or others attempting to include them).

I’ll have to talk about this with Will in detail, probably.

I made that statement assuming a transition as below. I don’t think that Package Control maintainers alone can enforce such a standard. It’ll have to be a community effort.

I won’t mind if he does get a say… But yes, I did not mention someone who definitely needs to be included in this discussion.

@wbond Your participation in this discussion is sincerely requested.

We should have a convention/standard in place for future packages and should ask the rest of the community to then do compatible renames. This will make it possible for us to transition the entire ecosystem to the new convention, so that after a (substantial?) grace time, we could enforce the convention converting it into a standard.

Some things to do if we do the transition:

• The end user should be notified about new name.
• The packages should have temporary aliases (to the old name) when renamed, to smooth the transition and these aliases should be removed at the end of the transition period.
• Open an issue on the repository of the package (most packages are github or bitbucket) and warn package authors about the change:

  The package name {name here} does not follow the new package name conventions being adopted by Package Control. Please change the name to something compatible with the new convention.

  Suggested Names:
  {Some suggestions here}

I do not think this is a small task but the consistency we will gain will definitely help the Sublime Text Package Ecosystem, IMO. Since the current naming system is very flexible, nearly any convention/standard which puts any restrictions will end up breaking some or the other package names.

As for the exact convention/standard, I have a feeling that should be discussed once we have consensus to even put one in place.

I feel that we need to answer a bunch of questions before we are going anywhere with this… And these will most-definitely be a part of that list.

• Do we (on some future date) enforce a naming convention?
• How big a change are we willing to take on vs what we want/should ideally have?
• Are we willing to put in the effort, as a community, to make the complete shift to a new convention?
  It is one of those all-or-nothing things. Everyone needs to shift over or it’s of no use.

Thinking about this again randomly, I actually like that packages have TitleCase names (most of the time) since an import implicitly tells you that you are importing from another Package and not a “usual” Python module. Case-sensitive file system or not.

Furthermore, I do not think we will do anything that would cause renaming many existing packages in the near future, if at all. What we could do however is not accept packages with spaces or other invalid characters for Python identifiers anymore, if they include plugins. That would include packges with leading numbers.

Otherwise, the conventions for <Lang> Snippets, <Lang> Completions,
<Lang> Syntax or Language - <real lang>, Color Scheme - <name> and Theme - <name> would be unsustainable.