Bundle snippets in a "Snippets" subdirectory?

[FichteFoll]

Some packages contain quite a few snippets, which creates a lot of noise in the package folder. I propose to move all snippets, or if they exceed a certain threshold (e.g. 4), to a new subdirectory called "Snippets".

[gerardroche]

Move them into their own package. Completions too. This allows the user to install alternative ones.

[FichteFoll]

How about being able to ignore only a subset of a package in a new setting? With that you could, for example, ignore all .sublime-snippet files with a pattern like "ignore_package_files": {"Java": ["*.sublime-snippet"]}.

That way it is more flexible and powerful and could be applied to any package.

Edit: Created issue for this: sublimehq/sublime_text#901

[jbrooksuk]

I think all snippets should belong in a Snippets directory, so I made a PR for it.

[aziz]

Why should it only be limited to snippets? I always disliked the lack of file organizations in Sublime packages.
Textmate 2 took a very structured approach

Something in between would be great.

[jbrooksuk]

I noticed that after moving the snippets the root directory was pretty sparse, so I don't think that there is much need to go further.

[FichteFoll]

Besides .tmPreferences, all other resource types are fairly limited for each package (menus, key binds, command palette, ...). And even these rarely go beyond 5, so I would base this on individual judgement.

Additionally, things that can be added indefinitely (syntax definitions, themes, color schemes) are usually the core part of a package, and packages usually aim to not be bloated with 100s of color schemes.

Anyway, for my own packages I adapted a structure to move all package resource files except plugins (which must be in the package root) in a "Package" subdirectory. This directory is then structured deeper into "Snippets" or "Syntax Definitions", if there are more files than a certain threshold. This has the advantage of having all repository-relevant files such as readme, license, files for Package Control are easy to catch in the root. Since we don't have any of these files here, I doubt this structure is necessary.

[jbrooksuk]

IMHO all default packages should follow a convention. Not base it on some arbitrary amount of files before they get moved into a sub-directory. Basically, all or nothing.

[gerardroche]

How about being able to ignore only a subset of a package in a new setting? With that you could, for example, all .Sublime-snippet files with a pattern like "ignore_package_files": {"Java": ["*.sublime-snippet"]}.

👍

IMHO all default packages should follow a convention. Not base it on some arbitrary amount of files before they get moved into a sub-directory. Basically, all or nothing.

👍 for a standard package structure

Even if a package only has one macro and a few snippets it's still nice to have everything in its place.

Spaces in file and folder names can be an issue, as can special characters on some symstems. Lowercase, dash-separated files and folders where possible.

| --- completions/
| --- keymaps/
| --- macros/
| --- menus/
| --- settings/
| --- snippets/
| --- syntaxes/
| --- tests/
| --- .gitignore
| --- .gitattributes
| --- CONTRIBUTING.md
| --- LICENSE
| --- README.md
| --- sublime-package.json

The complete structure above probably won't be possible until ST4 but it can be partially implemented. I don't see too many issues with moving snippets and completions around. There will be an issue with syntaxes because they are assigned via path. Would be good to be able to assign syntaxes by name or scope.

[jrappen]

I suggest:

/Package
    /build
        /linux
            *
        /osx
            *
        /windows
            *.exe
        *.sublime-build
    /color-schemes
        *.tmTheme
        *.hidden-tmTheme
    /commands
        *.sublime-commands
        *.tmCommand
    /drag-commands
        *.tmDragCommand
    /keymaps
        *.sublime-keymap
    /lib
        *.py
    /macros
        *.sublime-macro
        *.tmMacro
    /menus
        *.sublime-menu
    /messages
        install.txt
        *.txt
    /metadata
        *.tmPreferences
    /mousemaps
        *.sublime-mousemap
    /settings
        *.sublime-settings
    /snippets
        *.sublime-completions
        *.sublime-snippet
    /syntaxes
        *.tmLanguage
        *.hidden-tmLanguage
        *.sublime-syntax
    /tests
        *.*
    /templates
        *.*
    /themes
        *.sublime-theme
    .gitignore
    .gitattributes
    .no-sublime-package
    *.py
    CHANGELOG.md
    CONTRIBUTING.md
    LICENSE.md
    README.md

or some similar structure.

/cc @jskinner @sublimehq Feedback?

---

Updated with suggestions below.

[jbrooksuk]

Works for me.

[FichteFoll]

I like @jrappen's draft, with a few fixes:

1. "Plugins" is a weird, since it would require all imports to be written as from .Plugins import mymodule -- from the root anyway. This could be circumvented if Sublime Text would consider all .py files in a "plugins" directory to be plugin files and load them. I don't think I like that though, since it seems like an arbitrary restriction. Maybe add a new API that goes like sublime.load_plugins("./Plugins") that you can call from a file in the main directory?

   Another idea is to simply place Python modules in subdirectories with snake_case, which will hopefully be different enough from the TitleCasing of the ressource containers. (Which is basically the reason why I would support TitleCasing them in the first place.)

2. Why place build systems in "Support"?

There is a different issue that we haven't considered yet, btw: override files. They would have to be renamed (probably automatically), in case an ST user had some.

[gerardroche]

I would say lowercase folder names and maybe Schemes -> color-schemes

Add .gitattributes:

# files detected as binary untouched.
* text=auto

# Files and directories with the attribute export-ignore won’t be added to
# archive files. See http://git-scm.com/docs/gitattributes for details.
/*.sublime-project          export-ignore
/.gitattributes             export-ignore
/.gitignore                 export-ignore
/tests/                      export-ignore

And a CHANGELOG.md

I don't see "Plugins". If were talking about sub folder .py files I suggest lib/ as the base, and then that may have subfolders of its own. This way we know that the .py files will be in the root and in the lib folder and nowhere else.

[pradyunsg]

I just opened #32. Let's limit the discussion here to only snippets and move the whole package-wide organization discussion over to that issue.

[FichteFoll]

Closing since this was done in a149a7b. For other package structure discussion, use #15 #32.

Edit: Shifted lines while writing.

[pradyunsg]

@FichteFoll You mean #32?