I ignored the built-in Python package in order to only keep the syntax file and not the rest. I copied the syntax file in a folder of its own (“executable folder”/Data/Packages/Built-In/Python), it was recognized without any problems, but when I started typing I got the following error.
I followed the same procedure with JSON and JavaScript syntax and it worked fine.
Than maybe don’t mess with core packages if you are not knowing what you are doing.
I thought we were the Sublime Text forum, not Reddit. Don’t bring your toxicity here. Either make yourself useful, or shut up.
The point is renaming or moving packages will cause all sorts of errors with various 3rd-party packages if those extend base syntaxes.
It is just tiering to waste time trying to help people coming around with “I get errors” just to learn hours or days later they winded up their packages causing such issues.
Hence it is NOT RECOMMENDED to hack with core packages like that. If you do that you are on your own. Don’t complain about things not working, nor expect support!
Even if I leave the package untouched, it doesn’t work. I tried replacing the build system file with my own because I don’t have a traditional Python installation, and I need some flexibility later. I was advised not to modify pre-packaged packages, but rather to ignore them. That’s what I’ve done. I extracted the packages for the programming languages I need into a separate folder within the “Packages” directory to avoid conflicts with the original packages. I ignored the rest. Some are working, but these: Batch File, PHP, and Python, are the ones giving me trouble right now. PHP doesn’t even appear in the status bar now that I’ve ignored the packages I don’t need, which suggests a possible problem with dependencies.
If all you want to do is have a custom build system then you can simply override the built-in one by creating the same file/path in the Packages directory. I suggest using the OverrideAudit package to do this.
I’m trying to only keep the syntax highlighting for the languages I use, and start from there.
This is because e.g. PHP extends HTML and thus relies on HTML package being present and enabled and HTML.sublime-syntax being in its original location using correct name.
The same for Python. It embedds an extended version of Packages/Regular Expressions/RegExp (Basic).sublime-syntax.
Various core packages depend on each other as well as 3rd-party packages depend on core packages and their syntaxes being present, in correct (shipped with ST) version and not being renamed.
Even just disabling “wrong” core packages will cause you errors like that.
Copying all core packages and renaming them while keeping original ones in place is anything but efficient and smart.
Thank you for the clarification regarding interdependence. I’m not trying to be pedantic, but rather trying to have a bit more control over my environment. I switched from VS Code because I dislike the idea of pre-packaging features that may or may not be necessary (something VS Code excels at). I often found myself removing everything and adding only what I actually needed. I’m trying to replicate that granular control in Sublime Text (I greatly appreciate its customization capabilities so far). It’s not about being smart.
As a last question, could you tell me how to ignore sub-packages within a core package, as shown in the attached image?
These are just multiple sublime-syntax files located in JavaScript package.
As TypeScript, JSX and TSX are all based on JavaScript syntax, they are arranged in a single package - reducing inter package dependencies.
Those aren’t packages, they’re syntaxes that are contained within the JavaScript package (in your particular example here). Generally because they’re related or extend from one another.
In this example,
TSX extends JSX and TypeScript
JSX and TypeScript extend JavaScript
Since Syntaxes are only used to provide editor support for those particular kinds of files, they only ever have any effect on anything if you happen to open such a file, and they are loaded the first time that they’re needed. As such there is no need to remove them other than looking in this menu shows you things you don’t want to see (but by the same token if you’re looking in this menu that frequently, you probably have something set up incorrectly).
In any case, there are only two ways to actually remove such a thing should you actually want to do it, and with all of the caveats outlined above regarding how all of the core packages tend to rely on each other and you can serious bork/destroy/disable Sublime as a whole by trying to mess with them when you don’t understand the consequences (so be warned):
Look in the installation folder of Sublime, where the Exectuable lives. You will see a Packages folder there, and inside some sublime-package files; these are the packages that ship with Sublime. If you rename them to .zip and then modify the contents, then rename them back to sublime-package, the files will no longer be present.
Note however that the files in the installation directory are intended to be hands off by the user because Sublime updates itself by discarding the entire installation folder and replacing it with a new one (hence why your user configuration is not there).
As such every time Sublime upgrades itself, your change will be discarded without warning, which is why you should never, ever do this unless your life is too boring and you want or crave ongoing woe.
Similar to option one, except you take that sublime-package file, copy it out, edit it as desired, and then instead of replacing it in the installation folder, drop it into the Installed Packages folder in your user configuration area (NOT Packages!).
When Sublime loads the shipped packages, if a sublime-package with the same name exists in Installed Packages then it will completely ignore the one it ships with and use that one instead.
In this case, when Sublime upgrades itself, your change remains in place because it’s not in the installation folder.
However, this locks you into that particular version of that package, forever, with no direct warning. So, if a future version of Sublime adds new features or fixes bugs or otherwise enhances that package, you will not receive those benefits.
Further, if any of the other core packages rely on those changes, those packages will break for mysterious reasons, as will any third party package that does the same.
Thus, things are still dire, but perhaps less so in the short term, and things just sort of tend to get a bit rickety as time goes on.
If you want to go this route, I would recommend the OverrideAudit package mentioned above, which if nothing else will warn you if the shipped version of the package is newer than your version, so you can decide if you want to take action.
OverrideAudit's support for this is purely informational, unlike regular overrides where it can tell you what is different to help you edit them. To my knowledge, in the 8 years that the package has existed I’m the only person that has ever exercised its ability to tell you about this, and that’s only because I wrote the thing and needed to test it.
Probably worth noting that making changes such as these can make diagnosing problems quite difficult, particularly for people that don’t know the depth or scopes of the changes you made, which likely greatly constrains your ability to get help from the community in general.
Thank you everyone for your time and effort in helping me with this. I’ve explored the configuration options as much as I can, and I think I’ve reached the limit of what a regular user is allowed to customize regarding the core packages, as you mentioned. I’m going to stick with the system’s default configuration as intended by the developers. Thanks again for all your assistance.