Initial submission of Highlight Token.

[cepthomas]

• I'm the package's author and/or maintainer.
• I have have read [the docs][1].
• I have tagged a release with a [semver][2] 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.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• 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][3] to exclude files from the package: images, test files, sublime-project/workspace.

Highlight words in the current document/view with user specified colors.

• Persistence per file.
• User selectable (6) colors by new scopes.
• Select whole word or not.
• Show colorized list of the scopes at the caret, or all scopes in the view.
  This is an enhanced version of the built-in function.
• Works well with Render View to generate static output.

Loosely based on StyleToken but with persistence and better/easier customization. Also that package appears abandoned.

This is one of several plugins I'm submitting to Package Control for consideration. I've been
refining them for several years and use them daily. I think they could be useful to others, in whole or as parts.

[packagecontrol-bot]

Automated testing result: SUCCESS

Repo link: Highlight Token

Packages added:
  - Highlight Token

Processing package "Highlight Token"
  - All checks passed

[braver]

For some of these packages where you say "loosely based on", it get's close to where we would normally consider replacing the existing package. But it's not a fork, so for users everything would be different. So, let's not do that.

I wonder if it's smart to share logging and storage directories across your packages. For users it would be clearer if stuff is in a directory that belongs with each specific package. And I would argue that it's not necessary for those directories to be hidden. Sure, users don't need to go there, but it also hides them from users trying to debug something in their setup.

Finally, why is this package (and seemingly others you made) not compatible with MacOS? You seem to not rely on external processes, and python has all the tools you need to work in a cross-platform way almost transparently. Even paths, as long as you stay within bounds of Sublime Text, are trivial to deal with and mostly completely transparent. Is it just because for a few utilities in your common scripts you haven't found (or ar unable to test for, which I'd totally understand) a Mac alternative? Those might not even apply to this specific package. Unless I miss something, I would definitely advocate spending a bit of effort, or getting some help from the community in also supporting Macs: it looks like that should be within reach.

[braver]

PS, sorry your submissions have sat here for a while. This is a community project and I've been otherwise occupied these past few months. Checking a color scheme or metadata update is easy, but your submissions warrant some honest attention. So sit tight, we'll get to all of them eventually 🤗

[cepthomas]

For some of these packages where you say "loosely based on", it get's close to where we would normally consider replacing the existing package. But it's not a fork, so for users everything would be different. So, let's not do that.

I used StyleToken a lot for a while but its lack of features got in my way so I built my own. I use it constantly. I considered forking but it was too divergent.

I wonder if it's smart to share logging and storage directories across your packages. For users it would be clearer if stuff is in a directory that belongs with each specific package. And I would argue that it's not necessary for those directories to be hidden. Sure, users don't need to go there, but it also hides them from users trying to debug something in their setup.

I will make those changes everywhere. I think I found some examples with the common folder approach and just "picked one".

Finally, why is this package (and seemingly others you made) not compatible with MacOS? You seem to not rely on external processes, and python has all the tools you need to work in a cross-platform way almost transparently. Even paths, as long as you stay within bounds of Sublime Text, are trivial to deal with and mostly completely transparent. Is it just because for a few utilities in your common scripts you haven't found (or ar unable to test for, which I'd totally understand) a Mac alternative? Those might not even apply to this specific package. Unless I miss something, I would definitely advocate spending a bit of effort, or getting some help from the community in also supporting Macs: it looks like that should be within reach.

My stuff is quite generic so should mostly be mac-friendly. I think there might be one or two spots where macos was a bit difficult. I'll scan through again and have another look. I have no way to test though - would it be ok to put a notice in the readme to the effect of "not tested on macos but probably works, issues or prs invited"?

Again, these should be implemented before release. I'll do that asap.

[cepthomas]

PS, sorry your submissions have sat here for a while. This is a community project and I've been otherwise occupied these past few months. Checking a color scheme or metadata update is easy, but your submissions warrant some honest attention. So sit tight, we'll get to all of them eventually 🤗

No problem, I completely understand and appreciate your efforts. I just didn't want to get lost in the cracks!

[braver]

would it be ok to put a notice in the readme

Sure, that’s totally ok. In some cases I might be able to help out as well. We don’t normally test packages as part of the review, we’re mostly concerned with correct usage of api’s and packages not interfering with one another, etc. But if you need me to double check something let me know.