feat: add Tact package

[novusnota]

• I'm the package's author and/or maintainer.
• I have have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette. It doesn't add new commands, only a new build option, which gets into the command palette automagically.
• [ ] Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view. This package only sets indentation settings (4 spaces) for .tact files and doesn't add any keybindings, so I'm not sure this point applies here.
• If my package is a syntax it doesn't also add a color scheme. ***
• If my package is a syntax it is named after the language it supports (without suffixes like "syntax" or "highlighting").
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

My package is adding various support for Tact language: syntax highlighting, auto-completions, snippets, simple build integration and more. Full list of features is specified on the README.

Link: https://github.com/tact-lang/tact-sublime

There are no packages like it in Package Control. Hope everything's correct here :)

[novusnota]

@packagecontrol-bot

[packagecontrol-bot]

Automated testing result: SUCCESS

Repo link: Tact

Packages added:
  - Tact

Processing package "Tact"
  - All checks passed

[braver]

If you're not sharing the tmLanguage syntax with packages for other editors, I would suggest upgrading it to the sublime-syntax.

You might also want to consider contributing an LSP-tact package to help users install and set that up.

You're using some settings here that you don't expose to the user, that looks intentional to me? You can't guarantee users won't change settings afterwards though. But, it should help users start off with the "correct" or canonical defaults.

Anyway, looks good, thanks!

[novusnota]

If you're not sharing the tmLanguage syntax with packages for other editors, I would suggest upgrading it to the sublime-syntax.

Good suggestion — I've looked into it previously, and that syntax was much sweeter when specifying nested constructs. However, I indeed use tmLanguage syntax in a bunch of things: it's used in VSCode, Monaco (editor powering VSCode) and Shiki highlighting (for docs). And we've decided for the root of truth of the tmLanguage syntax to be in Sublime, because you have a neat testing system for highlighting in place!

You might also want to consider contributing an LSP-tact package to help users install and set that up.

Sure thing! However, the current LSP will rather soon be superseded by a newer one, so I'll be contributing it then :)

You're using some settings here that you don't expose to the user, that looks intentional to me? You can't guarantee users won't change settings afterwards though. But, it should help users start off with the "correct" or canonical defaults.

Yup, that's precisely the reason to set the indentation (and only it)

Anyway, looks good, thanks!

❤️

[braver]

👍🏻👍🏻