sublime-syntax.sublime-syntax #95

gwenzek · 2015-08-26T21:03:49Z

Meta syntax :-)
I tried to cover as much as possible from the Onigruma syntax.

FichteFoll · 2015-08-27T11:22:32Z

I have a few issues with that syntax.

I worked on a new yaml syntax definition in #90 and the lack of block scalars here is severe. Furthermore, quoted strings and their escape mechanisms are not accounted for and plain scalar termination rules (which are not that trivial, see more in YAML.sublime-syntax) neither. Oniguruma regex support could also be improved and should be split into its own definition, as is here.

Also, I acutally intended to work on a syntax def for this on my own, since I also maintain AAAPackageDev and this seemed like a good fit, but I wanted to wait for my YAML def to be merged first because I intended to re-use some contexts I defined there (and had different things to do afterwards).

Furthermore, I'm interested in a stance from @sublimehq regarding special syntax highlighting of its own configuration formats in the shipped packages, including all the JSON formats. In the past they were not obviously (which is the reason why PackageDev exists). It also seems that package development here has stalled because pull requests haven't been merged or reviewed in a while.

(It would also be nice if anchors/aliases and merge keys were actually implemented in sublime-syntax ...)

gwenzek · 2015-08-27T12:36:21Z

Thanks for your feedback @FichteFoll .

I'll work on scalar blocks.
I didn't give it too much thoughts because most of the time I quote my regexes.
I see you use a lot of

 ns_tag_prefix: |- 
    (?x:
        !              {{ns_uri_char}}*
      | (?![,!\[\]{}]) {{ns_uri_char}}+
    )

in your YAML syntax, and they aren't correctly highlighted. I think simple forms like that with grouping parenthesis could be easily added.
I didn't split the regex syntax because YAML double quoted strings changed the behavior of escaped character and therefore change the way the regex should be highlighted. Maybe it's do-able and it would be nice to have the regex syntax usable somewhere else.

But I think it would be interesting to have a syntax for .sublime-syntax, more precise than a YAML syntax in order to match the few keywords allowed and the regexes.
I checked it on several .sublime-syntax and the regexes look good, could you be more precise ?

I'd be happy to contribute to AAAPackageDev if @sublimehq think it's a better place to include such syntax.

FichteFoll · 2015-08-27T13:33:24Z

I checked it on several .sublime-syntax and the regexes look good, could you be more precise ?

What exactly do you mean here?

gwenzek · 2015-08-27T15:52:12Z

You said:

Oniguruma regex support could also be improved

So I was hoping that you could show me some examples of poorly highlighted code.

FichteFoll · 2015-08-27T16:51:53Z

I prepared this test file for myself a while ago. It will serve as the base for syntax tests if I eventually start working on this again, but I want to wait a bit first due to the reasons outlined above.

gwenzek · 2015-08-28T13:41:11Z

Thanks, I'll have a look at it and come back.

gwenzek · 2015-09-12T15:10:22Z

Hi @FitcheFoll, I used your test set and improved the regexes.

I also made a few improvements on character classes and scope lists.

gschenck · 2016-05-01T11:31:41Z

Highlighting is broken for

match: '(?<![\d.])\b0[xX][a-fA-F\d.]+([pP][-+]?\d+)?|\b\d+(.\d+)?([eE]-?\d+)?|.\d+([eE]-?\d+)?'.

Problem is "-?"

gwenzek · 2016-05-01T12:27:19Z

Hi @gschenck thanks for your report.
It looks fine to me, what's is the result you expected ?

I think the ? in this context is an operator but the - is a character.
Is -? having a special meaning in this context for Oniguruma regex ?

gschenck · 2016-05-02T04:48:43Z

Please have a look at https://github.com/sublimehq/Packages/blob/master/Lua/Lua.sublime-syntax,
highlighting stops at line 20.

gwenzek · 2016-05-02T20:04:51Z

@gschenck sorry I was testing with a more recent version of the syntax. I commited the new version here.

gschenck · 2016-05-03T05:53:10Z

Works. Thank you.

keith-hall · 2016-05-04T08:42:38Z

YAML/sublime-syntax.sublime-syntax

@@ -453,9 +453,9 @@ contexts:
  variable_call:
    - match: '(\{\{)([a-zA-Z_0-9]*)(\}\})'
      captures:
-        1: punctuation.definition.parameters.begin.syntax
+        1: punctuation.definition.arguments.begin.syntax


for my use, I added the line: 0: variable.parameter so that variables would be highlighted by the color scheme and thus be easier to spot :)

gwenzek · 2016-05-04T09:53:44Z

Thanks @keith-hall for your suggestions, I added them in.
I also added a test file.
It was working fine a few build ago but with current build (3111) the test file is not picked up by Sublime.

If any one has an idea on how to do this I'll be glad 😃

wbond · 2016-05-04T11:11:01Z

YAML/syntax_test_sublime-syntax.sublime-syntax

@@ -0,0 +1,44 @@
+## SYNTAX TEST "Packages/User/scalaSublimeSyntax/sublime-syntax".sublime-syntax"


This line should be ## SYNTAX TEST "Packages/YAML/sublime-syntax.sublime-syntax".

That is why your tests aren't being picked up.

FichteFoll · 2017-07-05T22:14:32Z

As a note, I added my own sublime-syntax highlighting to PackageDev, which has a lot of other goodies for syntax (test) development too. It's still in "alpha" because I want to finish all the other syntaxes as well, but it's very usable and an absolute must-have for anyone who works on syntax definition (not an under-statement).

See https://forum.sublimetext.com/t/looking-for-packagedev-alpha-testers-sublime-syntax-highlighting/24270 for the announcement thread.

deathaxe · 2018-06-19T18:30:51Z

As PackageDev is indeed a very helpful package not only for syntax development but handling all the different sublime-text-file-formats by providing functionalities which go far beyond syntax highlighting, I wonder whether this PR is still required to be open.

bumfo · 2019-09-03T06:26:50Z

As PackageDev is indeed a very helpful package not only for syntax development but handling all the different sublime-text-file-formats by providing functionalities which go far beyond syntax highlighting, I wonder whether this PR is still required to be open.

I think PackageDev shouldn't be required for basic syntax editing, maybe including their sublime-syntax.sublime-syntax with default Packages is an alternative.

FichteFoll · 2019-09-03T09:31:36Z

I think PackageDev shouldn't be required for basic syntax editing

It isn't. There is a syntax definition for YAML that you can easily use to edit syntaxes (and apparently wbond only uses that), so it's perfectly possible to edit syntax definitions without PackageDev. However, I wouldn't recommend it and installing a third-part package is arguably trivial.

Furthermore, it allows us to provide more functionality that goes beyond highlighting, as @deathaxe mentioned, like context completions, scope name completions and the syntax test stuff with a much higher release frequency than would be possible with having the package in the default packages. Of course, it would still be nice if ST shipped syntax definitions for its config files, but as the maintainer and main developer of PackageDev, I enjoy the freedom in deployment and independence I currently have.

bumfo · 2019-09-03T10:02:18Z

I think PackageDev shouldn't be required for basic syntax editing

It isn't. There is a syntax definition for YAML that you can easily use to edit syntaxes (and apparently wbond only uses that), so it's perfectly possible to edit syntax definitions without PackageDev. However, I wouldn't recommend it and installing a third-part package is arguably trivial.
Furthermore, it allows us to provide more functionality that goes beyond highlighting, as @deathaxe mentioned, like context completions, scope name completions and the syntax test stuff with a much higher release frequency than would be possible with having the package in the default packages. Of course, it would still be nice if ST shipped syntax definitions for its config files, but as the maintainer and main developer of PackageDev, I enjoy the freedom in deployment and independence I currently have.

I appreciate the convenience provided by PackageDev, and the sublime-syntax.sublime-syntax from PackageDev is also full-featured. However, not everyone is looking for full support, nor all the other awesome features from PackageDev, when only basic editing of sublime-syntax is needed.

Currently YAML isn't an alternative, as it doesn't support indexing. I think a default syntax with only basic functions should be shipped by default, and only when more features are needed, install the package.

Installing a Package is, yes, trivial, but the overhead of installing features not needed causes many troubles, e.g. conflictions, which can all be avoided by including only necessary features.

jfcherng · 2019-09-03T10:38:16Z

I would consider editing a .sublime-syntax file as advanced thing for a user.

Another reason why I don't like things to be added as default package/syntax: It just updates SUPER slow due to ST's release cycle. Sure, there is a way that people can manually update it locally but installing a package is far simpler...

I am not against approving this PR because I can still and will use PackageDev whatever.

Another question here. If we are going to have a default sublime-syntax.sublime-syntax, why not take Sublime Text Syntax Definition.sublime-syntax from PackageDev directly since it's MIT licensed? Is this PR better, in any reasonable aspect (I do not mean to be rude, just curious)?

FichteFoll · 2019-09-03T20:45:37Z

The PR is basically a meta question whether to include a syntax definition at all at this point. At least that's how I perceive it. However, I'm not the person to decide here.

PackageDev's syntax definition is not self-contained, because it uses the separate syntax definitions for Oniguruma regular expressions and the generic JSON-focused context library I built for many ST configuration files. They could of course be embedded or included, but it's not as simple as just taking a single file and be done with it.

While I would of course be okay with ST including a syntax definition for syntax definition by default, it then raises the question about the other files like settings or build system. And, because of what @jfcherng said, I would still want to develop PD in parallel because of quicker release cycles and the fact that many extra features provided through plugins are strictly dependent on tokenization of the files with the syntax definitions. I would also need to check how well they override each, which is based on the lexicographical order of the package names.

@bumfo, maybe you could clarify on your areas of concern regarding conflicts of the features that PD provides?

wbond · 2020-07-22T14:06:19Z

I think for right now it makes sense that https://packagecontrol.io/packages/PackageDev be the place for augmented syntaxes.

The release cadence is separate, there is a group of people who are enthusiastic about what it provides, and the average user does not get into writing syntaxes. If they do, the default YAML syntax does work, I mean, I use it. 😄

We may revisit this at some future point, but for now I am going to close.

gwenzek · 2020-07-23T11:31:38Z

Good for me :-) I totally forgot about this PR.

gwenzek and others added 11 commits August 26, 2015 23:00

adapt yaml syntax to sublime-syntaxx syntax

8c286d4

better highlighting in yaml unquoted regex

04650af

more constraints on sublime-syntax syntax

9feed04

scope refactoring

b37cbdd

provide support for pattern val declaration

fe97afa

renamed YAML/sublime-syntax.sublime-syntax scopes

8d60fda

renamed constructor scopes

183c5ef

fixed recursion problem in sublime-syntax syntax

ebce660

add TODO detection

ce2bd42

unified separator colors logic

b1bcb9a

bad scopes on closing double-quotes

b1c47e6

gwenzek added 6 commits September 12, 2015 17:06

improve support for regex spanning several lines

f462c70

improve character classes

a9bb590

add sublime-syntax test

e2c66cc

add nested character classes

c323085

refactoring, add support for comment tag

d203985

handles scopes list

a1a52f1

fix issue with Lua syntax

63bb443

keith-hall reviewed May 4, 2016
View reviewed changes

add test file + suggestions from @keith-hall

f7c6211

wbond reviewed May 4, 2016
View reviewed changes

keith-hall mentioned this pull request May 21, 2016

Scope for keys in mappings/dictionaries (e.g. JSON, YAML) #421

Open

FichteFoll mentioned this pull request Aug 15, 2016

[XML] add [sublime-snippet] syntax definition #576

Closed

wbond closed this Jul 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sublime-syntax.sublime-syntax #95

sublime-syntax.sublime-syntax #95

gwenzek commented Aug 26, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 27, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 27, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 28, 2015

gwenzek commented Sep 12, 2015

gschenck commented May 1, 2016

gwenzek commented May 1, 2016

gschenck commented May 2, 2016

gwenzek commented May 2, 2016

gschenck commented May 3, 2016

keith-hall May 4, 2016

gwenzek commented May 4, 2016

wbond May 4, 2016 •

edited

Loading

FichteFoll commented Jul 5, 2017 •

edited

Loading

deathaxe commented Jun 19, 2018

bumfo commented Sep 3, 2019

FichteFoll commented Sep 3, 2019

bumfo commented Sep 3, 2019 •

edited

Loading

jfcherng commented Sep 3, 2019 •

edited

Loading

FichteFoll commented Sep 3, 2019 •

edited

Loading

wbond commented Jul 22, 2020

gwenzek commented Jul 23, 2020

		@@ -0,0 +1,44 @@
		## SYNTAX TEST "Packages/User/scalaSublimeSyntax/sublime-syntax".sublime-syntax"

sublime-syntax.sublime-syntax #95

sublime-syntax.sublime-syntax #95

Conversation

gwenzek commented Aug 26, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 27, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 27, 2015

FichteFoll commented Aug 27, 2015

gwenzek commented Aug 28, 2015

gwenzek commented Sep 12, 2015

gschenck commented May 1, 2016

gwenzek commented May 1, 2016

gschenck commented May 2, 2016

gwenzek commented May 2, 2016

gschenck commented May 3, 2016

keith-hall May 4, 2016

Choose a reason for hiding this comment

gwenzek commented May 4, 2016

wbond May 4, 2016 • edited Loading

Choose a reason for hiding this comment

FichteFoll commented Jul 5, 2017 • edited Loading

deathaxe commented Jun 19, 2018

bumfo commented Sep 3, 2019

FichteFoll commented Sep 3, 2019

bumfo commented Sep 3, 2019 • edited Loading

jfcherng commented Sep 3, 2019 • edited Loading

FichteFoll commented Sep 3, 2019 • edited Loading

wbond commented Jul 22, 2020

gwenzek commented Jul 23, 2020

wbond May 4, 2016 •

edited

Loading

FichteFoll commented Jul 5, 2017 •

edited

Loading

bumfo commented Sep 3, 2019 •

edited

Loading

jfcherng commented Sep 3, 2019 •

edited

Loading

FichteFoll commented Sep 3, 2019 •

edited

Loading