Sublime Forum

Looking for PackageDev alpha testers (.sublime-syntax highlighting and a lot more)

#21

Thanks for the feedback.

Most (if not all) of the regular expression scopes are inherited from the one shipped in the default Regular Expressions package. That doesn’t mean they are set in stone, but I didn’t specifically change any of them. I’ll certainly look into \d. What other scopes are you thinking of however? Support?

entity.name.<descriptor> is the proper way to name entities and standardizing these in the long run should be our goal. Especially the constant one should most likely be used by most other languages and color schemes most likely want to color these differently from other entity.name scopes.

I do want to check the new syntaxes for packagedev with default packages, mostly monokai since that is by far the most commonly used, but thanks for the reminder. Testing how the syntax works for different schemes is part of this “alpha”. What color scheme do you use?

1 Like
#22

This is the reason, why SublimeText should/must publish an updated version of standard scopes which may cover the requirements of most languages so color schemes can be updated. Right now many color schemes are tuned to certain languages only, due to none standard scope namespaces.

0 Likes
#23

I’m using a modified version of Espresso Libre, but I also tried it with Monokai which is apparently a popular scheme.
IMHO the regexes \d, \w, \s, so should be either constant.language or maybe support.constant.
I scoped \{, \[, \n with constant.character.escape in order to signify that they represent only one character.

For the discussion about the scope naming of entity.name.<something> I don’t want to hijack this thread, and since you followed the conventions I can’t blame you.
All I see is that now I’ll will have to add an entity.name.context to work with syntax definitions, a entity.name.struct to work with C++, a entity.name.interface to work with Java, and so on …
I jut hope nobody starts to differentiate between function, method, property …

@deathaxe https://www.sublimetext.com/docs/3/scope_naming.html#entity

0 Likes
#24

Yeah, I agree.

You are supposed to scope entity.name directly and match all other sub-scopenames with it. Then add special cases as overrides.

1 Like
#25

Thanks for the tip

0 Likes
#26

I’m using support.class now (which works with Monokai) for \d. Since \{ and the like were already constant.character.escape, I didn’t choose that. I also didn’t choose constant.language because I figured most schemes would not have special coloring for constant.character.escape (like mine does). While I was at it, I additionally pushed a few changes after other feedback that I haven’t committed yet.

I also poked Will to add some proper selectors to the Monkai scheme so that it will highlight my variable.other scopes, which it currently does not at all. Other than that, it should work generally okay.

If I had more time I would rewrite all the other syntaxes in this package too, but unfortunately I don’t, so this will need to wait a bit more.

0 Likes
#27

Been using this package for a month or so on non-trivial modes. Some thoughts thus far:

  • Very nice. A net win for productivity once I got used to the fact that there was highlighting to begin with (i.e. not just YAML mode)
    • Cmd-R for contexts is alone worth the price of entry
  • Regexes using double-quotes (") are not scoped the way that single-quoted regexes. See the Java mode for many examples
  • The |- operator is scoped somewhat strangely, at least in conjunction with an extended regex. See the Scala mode (base-constants context) for an example
  • Have you considered fiddling with auto-indent a bit? It should be possible to do better than the stock YAML rules.
0 Likes
#28

This is on purpose, kind of. Since double-quotes use backslashes for escape sequences, regular expressions start looking really ugly and would require me to almost copy the entire syntax definition, so I decided to just highlight variables and normal YAML escapes. You should almost always be using single quotes anyway, and this will “help” make the switch.

Looks perfectly normal here.

Can you provide an example where it doesn’t behave as expected? I haven’t had any frustrations with auto-identation.

0 Likes
#29

Depends on your color scheme:

The - is storage.modifier, while the | is punctuation.definition.

No frustrations, I just think it could be even better. An example would be something like this:

  - match: 'foo'
    # this should be auto-indented one step further
  - match: 'bar'      # and this would presumably be unindented

context-name:  # presumably also this
0 Likes
#30

Ah yes, that was indeed weird. I actually changed that long ago for the default YAML package, but forgot to push and pull request the branch. I did so last week, however, and I also made the change for the sublime-syntax syntax, but didn’t push that yet (that’s why it looks different in my shot).

Well, this is a curious case. Regarding the first comment: That should be doable. It seems more likely to add a second key-value pair to the mapping instead of a new sequence item. It would like if it ws as possible to cause ST to indent by two levels for situations where you have - match: |-, but that’s not possible without a plugin and I’d rather not add that.

The second comment might be doable as well. I’ll have to experiment with the indentation settings a bit. It will only work reliably after a single-line key-value pair however, so I’ll only add heuristics for that.

I don’t understand what the third comment is supposed to express, and would rather not add too much magic. The other comments so far were more about generic YAML.

0 Likes
#31

Thinking about what rules would be involved in the third one, there’s basically no way to do it deterministically. So… bad idea! :slight_smile:

0 Likes
#32

By the way, since this is actually an issue (or enhancement) wird the default YAML package, you should create an issue there with a reference to this thread.

0 Likes
#33

I am using this package and am very happy with it overall.

The only thing that I find lacking is a lack of support for YAML tags. While these don’t have any significance to Sublime, I’m using them extensively in my build system. For example:

    - match: !word SELECT

A python script compiles this to:

    - match: (?i)\b(?:SELECT)\b

The YAML package correctly highlights !word as storage.type.tag-handle.yaml and SELECT as string.unquoted.plain.out.yaml. But this syntax doesn’t expect the tag, so it tries to interpret the entire line as a regex, producing invalid.illegal.expected-string.sublime-syntax.

My ideal behavior would be for the tag to be highlighted as it is in plain YAML and for everything else to remain the same.

0 Likes
#34

Interesting usage. Yes, I can certainly add tag support for sublime-syntax highlighting; it should be trivial. I just never considered it because it’s never going to be useful if you directly edit the file to be consumed by ST.

Corresponding issue: https://github.com/SublimeText/PackageDev/issues/93

0 Likes
#35

Since I’m in this thread now anyway, I might as well post a status update.

@kingkeith has done a lot of work on new syntax definitions for sublime-snippet, tmPreferences and sublime-keymap files as well as smart completions for syntax test (:heart:) . I’m slowly merging and integrating these into the code base, while making adjustments and restructuring the package.

Expect a new alpha release with these within the next week or two.

We’re also working on command name completions in various places (keymaps currently, but other places to follow; even .run_command in plugins). Shout-out to @r-stein.

3 Likes
#36

A new pre-release is out. :tada:

Key features include:

  • Entirely new syntax definitions for:

    • sublime-snippets
    • tmPreferences
    • Property Lists in general (relevant for tmTheme)
    • sublime-keymap

  • Auto-completions for syntax tests.

Note: All syntax definitions have been moved or renamed within the Package. As a result, you will most likely notice error messages from Sublime Text reporting missing files. Just close and re-open files that this package provides syntax highlighting for.

Here’s a preview of the new sublime-keymap highlighting:

https://x0.at/UUf.png

As always, please make sure to report any issues you run into: https://github.com/SublimeText/PackageDev/issues

6 Likes
#37

Do they inherit from the regular JSON syntax definition? Or do they include the scopes punctuation.? :worried: Looks awesome anyway!

0 Likes
#38

The syntax is fundamentally based on the regular JSON definition (with score names and a few includes of the generic JSON data types), but most of it is custom highlighting on top of it. You can always take a look at the underlying syntax definition.

The next alpha release will use meta.mapping.key.json string.quoted.double.json for all keys with some having an additional scope at the end, such as the main keys. This will (hopefully) also be part of the next ST dev release. See https://github.com/sublimehq/Packages/pull/862.

0 Likes
#39

Finally another update, this time with lots of goodies for settings, thanks to @deathaxe.

I’ll let this video speak for itself:

https://x0.at/Fx-.mp4

On another note, this is the first beta release, though this is merely a new name. I consider the package to be generally pretty stable (also considering the few reports I get) and the only thing left for a 3.0 release is feature parity with the syntax definition rewrite.

6 Likes
#40

It’s time for another big PackageDev update.
With this, we are nearing a release candidate (and stable release), since only few things are left
to do now.

This latest release brings you:

  • Completions of command names and arguments in all resource files that support them (@r-stein)
    This includes the JSON files as well as Python plugins!

  • Rewrites of all relevant syntax definitions from tmLanguage to sublime-syntax
    (with the help of @r-stein)
    Now with very precise highlighting for:

    • build systems
    • commands files
    • completions files
    • macro files
    • menu files (new!)
    • mousemap files

  • Additionally, snippets and completions (within strings) wherever they made sense

  • Unified “New *” command with more templates for more resource file types

  • Suggests to create this file in the current project, if it is a package

  • Supportive deprecation warnings in tmPreferences files when Sublime Text wouldn’t pick up a
    string’s content after a comment or CDATA tag (@kingkeith)

  • Settings completions fixes and improvements (with help from @deathaxe)

  • Various other fixes (and a lot of refactoring)

If you’re feeling curious, this release has a lot of commits which you can inspect here: https://github.com/SublimeText/PackageDev/compare/v3.0.0-beta.3...v3.0.0-beta.4. (No, I’m totally not doing this because of how much work this release was compared to the rather little visible changes.)

5 Likes