Enabling and Disabling of Certain Package Features

[Remi]

So I’m investigating a few things I could add to my language package that might be beneficial however these things are very likely to be somewhat personal or system driven and I’m not sure how the customization might proceed.

1. Build system – For the language there are a number of different tools that could be used to build it. It could be as simple as running make if they set it up that way. It could be more complex like a single line compile. Or run a TCL script. Basically the variations are if not endless, then at least a fairly large solution space. So it’s difficult if not impossible to write something that’s going to solve everyone’s problem. At the same time, it feels kind of chintzy that there’s NOTHING to start from in terms of build systems.

So… if I create a basic build system that would execute one of the solutions (a fairly common tool) and parse the results, is there a way the user can easily expand or customize that? The build system would be in the package (so zipped up and relatively unaccessible for easy editing) so I don’t know if they can open the current embedded build system, and then save it in their project file and it’ll override the basic.

Another thought I had, I could try to create a snippet or command+snippet that would aid the user in creating a build system for their system. Not quite as out of the box useful, but has the potential to be FAR more customizeable. I have thought of trying to add additional fields into a *.sublime-project file that would keep the customization aspects local to that project.

2. Indentation – I started playing with the automatic indentation preferences. It’s clear to me that this is one of those things that could be very personal or style variable. I’ve seen a lot of code styles for my language, and some are a bit wackier than others. If I create a default indentation ruleset, can the user turn it off, or easily modify it? The default “keep next line indent the same as current line” will get a person pretty far, but I don’t want my default style to be an annoyance if it’s not what the developer desires.

[OdatNurd]

So… if I create a basic build system that would execute one of the solutions (a fairly common tool) and parse the results, is there a way the user can easily expand or customize that? The build system would be in the package (so zipped up and relatively unaccessible for easy editing) so I don’t know if they can open the current embedded build system, and then save it in their project file and it’ll override the basic.

Assuming your package is installed as a sublime-package file, your users would have to use something like PackageResourceViewer to get at the files, where their modifications would override your default implementation. One of the implications of this is that any updates or changes you make will be lost on them (although they could use OverrideAudit to detect the situation and take appropriate action).

You can set your package to not be installed as a sublime-package, in which case the files would be stored in the package directory for easier access, but in that case when you update your package their changes would get clobbered over, which is also less than ideal.

If you’re going to make your own customized build system (i.e. by using a custom target in the build) then you’re open to being able to control how it works in ways that using the default target of exec cannot, so that may be a way to go.

For example, you could support a setting in the build file that points at a file (in say the User package or project directory) that controls the build or provides extra information to it, which would allow your user to customize files in locations where the changes won’t cause problems. You could tie that with your snippet idea to easily create the skeleton for such a file and guide the user through filling it out.

Going this route you would probably want your custom build to start off being as useful as is possible without custom configuration so that it’s still of some use to people that haven’t made any customizations yet.

If I create a default indentation ruleset, can the user turn it off, or easily modify it? The default “keep next line indent the same as current line” will get a person pretty far, but I don’t want my default style to be an annoyance if it’s not what the developer desires.

Possibly a user could use a syntax specific setting on e.g. auto_indent and/or smart_indent to turn the feature off entirely for your syntax, but that may make things worse rather than better. On the whole I think the only way to modify the indent rules is to modify the tmPreferences file that’s specifying them.

This has the same caveats as above except that missing changes to indentation is less tragic than missing bug fixes in a build, for example. My own gut feeling would be that modifying indent rules with an override to suit your own tastes seems more “natural” a thing to do when customizing your tools to your liking.

In any case, indentation preferences is one of the great holy wars, so you can assume that no matter what you do (including not providing custom indent at all), you’re going to hear about it from someone that’s unhappy with your decision.

[Remi]

Going this route you would probably want your custom build to start off being as useful as is possible without custom configuration so that it’s still of some use to people that haven’t made any customizations yet.

Yeah, the idea of creating snippets that could be used if someone edited their project file might be a better way to go. That way, they are right there in the middle of the process and able to customize to taste.

In any case, indentation preferences is one of the great holy wars, so you can assume that no matter what you do (including not providing custom indent at all), you’re going to hear about it from someone that’s unhappy with your decision.

Yep and that’s why I largely haven’t touched that until recently (and to be perfectly honest, wasn’t even aware there was much to be done there until the Indentation thread came to life). Now, I did have to take some basic stands on indentation with the beautifier but I tried to support at least three common styles and wrote things to accomodate some of the weirder styles without too much pain. But there’s a huge difference in indentation that you apply after the fact (pretty printing, beautification, what-have-you) and automatic editing while you’re typing. The latter is a lot more invasive.

I definitely decided that with indentation, that’s a file I’m keeping in my local package and just tinkering with. I want to have a lot of experience on what feels good to type with before I try adding that to the package.

Build systems, the snippet system solution is starting to call to me, so I may journey down that path. I need to investigate what’s possible with project files some more. (Have been reading the unofficial docs).

[ThomSmith]

1. Create a MyPackage.sublime-settings file with reasonable defaults.
2. Make all of your Python scripts consult the appropriate settings for the functionality they provide.
3. Create a build system that takes in settings and template files and builds your tmPreferences file and so on.
4. Write a plugin that listens for changes to the user’s personal MyPackage.sublime-settings file and rebuilds the package.

I’m actually working on an implementation of this for my upcoming JS Custom package. You specify optional features, like JSX or Flow support, or highlighting literal object keys, and it dynamically builds a custom syntax using YAML Macros.

[Remi]

I will have to hammer this one out eventually I’m sure. There are definitely some things I could parameterize in my module behaviors but doing something comprehensive enough to generate a full tmPreferences is likely beyond my skills for the moment anyhow.

Probably need to figure out an information passing method to pursue as well for settings. I tried (and succeeded) in creating compartmentalized modules, ones that understand the ST3 API and perform the procedural tasks each command requires, and ones that just understand the language and don’t know anything about the API. However the more I abstract certain behaviors, I’ll need ways to get settings out (through the API) and then convey them to the language specific methods. (Mostly just thinking out loud here as I type.)