Sublime Forum

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

#19

Looks brilliant, thanks.

0 Likes
#20

Hi FitchFoll, thanks for working on that.

I see you choose to not provide support for “\\” regexes like me, it’s indeed a bit tedious to write, and it will encourage syntax writer to uses the cleaner simple quote syntax ‘\’.

Comparing to my syntax,
I feel sad that you didn’t provide standard scopes for context name.
You put an “entity.name.context” on it meaning it would probably looks like crap in most color scheme.
Same thing for the “entity.name.constant”. I personally used “entity.name.class” and “entity.name.function”.
I know it’s the direction Wbond took by introducing “entity.name.struct” and others, but I think this hurts ST in the long term.

Anyway I think you could use more different scopes for regexes. Most of the thing are highlighted as “keyword.control” and “keyword.operator” which have often the same color. Plus I don’t see why ‘\d’ is a ‘keyword.control’ and not a ‘constant.language’.
But I like how ‘meta-scope’, ‘match’ and ‘push’ are scoped differently.
I think you should try your syntax with the various Default color scheme to see how it looks like.
Ideally one should not have to fine tune it’s color scheme for each language he uses.

Regarding the multi-line support I can’t say much since my syntax don’t usually rely on those.

So apart for this scope knit-picking, I think it’s a good job, and splitting the Onigurama regex into it’s own file will probably prove useful.

1 Like
#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