-
Notifications
You must be signed in to change notification settings - Fork 588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundle snippets in a "Snippets" subdirectory? #8
Comments
Move them into their own package. Completions too. This allows the user to install alternative ones. |
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 That way it is more flexible and powerful and could be applied to any package. Edit: Created issue for this: sublimehq/sublime_text#901 |
I think all snippets should belong in a |
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. |
Besides 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. |
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.
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. |
I suggest:
or some similar structure. /cc @jskinner @sublimehq Feedback? Updated with suggestions below. |
Works for me. |
I like @jrappen's draft, with a few fixes:
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. |
I would say lowercase folder names and maybe Add
And a CHANGELOG.md I don't see "Plugins". If were talking about sub folder .py files I suggest |
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 You mean #32? |
Git Config: add fixes for embedded multiline shell scripts and indention rules
…ate-group-start-logic [Regular Expressions] Add other_modifiers variable
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".
The text was updated successfully, but these errors were encountered: