There is an issue with loading syntaxes when opening projects that have an existing workspace. Please see github.com/gerardroche/sublime- … r/issues/9

As far as I can see, that’s an inevitable consequence of disabling packages: when a session is restored that refers to those packages, you’ll get an error message. The behavior hasn’t changed here compared to pre-3087.

Yep. This has always been issue. Would be nice if ST handled this a little bit better and re-applied the new syntax. I can understand an error installing a new package while ST is opened. But all projects that have a workspace file cause this issue.

I think this will also happen for everyone after they update to ST with the new syntax. A better error message might help.

i am sorry to sidetrack but i would like to have jps at least acknowledge this contraintuitive behaviour and maybe state if this is ever gonna be changed

[quote]if the scope added with addRegion does not have a background color its foreground is used to fill the background and font color stays

[/quote]

i would like this to change only the font color and keep the background intact, especially ordinary vs current line background color

Thanks for the update seems to be working fine.
Reading the change log I hoped you would have fixed the problem I had earlier with recursion in prototype in .sublime-syntax
But Sublime is still crashing and won’t launch again until I remove the corrupted .sublime-syntax.

See here for code samples to reproduce the bug: https://github.com/SublimeTextIssues/Core/issues/850

Work on .sublime-syntax has been much appreciated thus far; I’m finally tackling a syntax I had wanted to build a couple years ago but found the tm syntax discouragingly tedious.

Do want to request that the “syntax_test” prefix requirement be loosened a little to allow for 1.) “syntax_test” prefix as current, or 2.) all files in a “syntax_test/” directory.

If this change happens, it’d be nice to also get an option to test the entire directory at once when this case is detected (EDIT: looks like it actually tests them all already , and to treat the syntax path as relative to the directory syntax_test/ is in. For the syntax def I’m working on, having multiple files necessary if I want a meaningful/compilable syntax test case, because each file is treated a class in the language I’m writing for, so testing any inheritance/super features requires a minimum of two files. Additionally, having multiple files has allowed me to isolate some complex language features in their own files where they can be more clearly exhausted of edge cases than they can be in a monolith.

@gwenzek I missed the original post, the issue will be fixed in the next build

@abathur, I’d be curious to see your tests when you feel they’re ready. I’d like to add tests for my project and it would be a great help to see how others are tackling it.

@bathos Sure. The project is up on github already, though I haven’t really started tackling the “test” part of writing of the tests yet. If it’s easier for you to just follow along for progress there, you can find it at: github.com/abathur/SublimeLPC

My focus up to now has been getting a reasonably representative language sample put together, making sure it compiles on the target environment(s), and resolving visibly-obvious matching issues. The files are roughly ready to start adding test comments, but now I need to go back and do some decision-heavy work of naming scopes. Yuck.

@bathos I have made some test for my scala syntax on my Github, you can have a look at it.

It’s a bit tedious to write but it’s quite helpful to spot regressions .

Also I’d like the test syntax to be expanded

Currently

// ^scope.name 

Will check the scope for the targeted character for some scope.

Could we write something to check several character at once, like:

// ^^^^scope.name 

Also support for negation would be nice, it’ll allow to check more easily the end of some meta scopes.

// !^ scope.shouldnt.be.there

When are you going to add printing functionality? One of the easiest things to do. Every editor out there has the ability to print. Why go to another program to print? Makes no sense.

I’ll second @gwenzek’s comments on test syntax, and add some points:

• When the first line of the file matches a syntax test, it would be nice to get some related interface improvements. The foremost of these is probably highlighting the background of characters which would be under test according to the currently selected comment line. Once a test block has grown several lines long, it gets hard to tell (quickly) if a caret is in the correct column.

• It would be nice to have either direct syntax or perhaps just an idiom for declaring future intent to test against a character. I thought sticking TODO: early on in my comment line would be sufficient to stop it from being run as a test, given how the documentation describes the syntax, but the tests still ran.

• @gwenzek mentions the ^^^^^^^ test this range format, and I’d suggest generalizing this to testing every position with a caret preceding the scope, so that we could for instance indicate the 5 locations in one line that should match an operator scope with a single comment instead of 5 comments.

May have more later.

I’ve been using ST for several years now and never even realized this was missing

[quote]

Also support for negation would be nice, it’ll allow to check more easily the end of some meta scopes.

// !^ scope.shouldnt.be.there

This is already possible using the usual scope selector syntax of “-scope.shouldnt.be.there”.

@FichteFoll Thanks for this note.

To follow up my own post on refinements/issues:

• I’m currently using the /**/ block comment for pending tests (i.e., this test would fail today, but someday we intend to match this scope at this position) as a stopgap.

I guess the “ideal” functionality would be if we had another prefix character to indicate that a scope should still be tested, but be allowed to fail (possibly just a ‘?’ as the first character of the scope?). Failure could probably be silent unless at least one passes, in which case we’d get a report on the pass/fail of all pending tests. This way the added visibility can guide our work on matching a new feature (i.e., all of the old tests continue to pass, and then we iterate on the match until all of the pending tests show up visibly as passing.)

If the logic required it, this could be a suffix to the “comment token”, but it seems like a prefix to the scope would be most flexible (i.e., 3/4 of the scopes specified at a position can already match fine, but the last is marked pending).

• There’s an issue with testing scopes when the code contains tabs. This is most-likely a known issue, but I didn’t expect it from the docs when I started. I’ve also reported this one to the tracker (github.com/SublimeTextIssues/Core/issues/886) though I haven’t created issues there for anything else from this discussion yet.

• There’s also an issue that I suspected would crop up sooner or later, where the comment/test lines break a multi-line code structure that needed matching. I can think of a few ways around this one, but they all basically involve a syntax for putting the comment later in some safe location and then specifying what line to test it against. I think my favorite of these is a line-offset syntax (i.e., +/-5]), which would minimize maintenance. Below is an example, which I’ll explain first: The A case will compile, and the entire block would correctly end up with the scope meta.preprocessor.macro.lpc, but the B block is both invalid LPC, and the injection of the line comments will break the matching of the macro.

//A
#define VERSION(MAJOR, MINOR, MICRO) ( \
	MAJOR * 1000000 + \
	MINOR * 10000 + \
	MICRO \
	)

//B
#define VERSION(MAJOR, MINOR, MICRO) ( \
    MAJOR * 1000000 + \
    MINOR * 10000 + \
    MICRO \
// <- meta.preprocessor.macro.lpc
//        ^ punctuation.separator.continuation.lpc keyword.other.line-continuation.lpc
    )
// <- meta.preprocessor.macro.lpc

Has anyone looked into automating syntax tests for CI integration yet?

You could play around a bit with github.com/randy3k/UnitTesting. Then you need to write a unittest suite that runs the syntax tests and compares results.
The tests themselves are triggered using the “run_all_syntax_tests” command, which internally calls the “hidden” sublime_api.run_syntax_test API, and writes the results to the “exec” output panel. Thus, you either need to run the above command and compare output or run the run_syntax_test API yourself (suggested, since it allows you to only run the tests in your package).

sublime_api.run_syntax_test expects a single parameter specifying the syntax test file to run, relative to the Data directory (as returned by sublime.find_resources), and returns a string with the error text, if any. That means a test failed when it returned something that evaluates to True.

Actually, I think that this kind of test could be run by UnitTesting directly (maybe optional) since it would be the same for all kind of syntax tests anyway.

Problem: .sublime-syntax is still only on the Dev builds and to my knowledge, UnitTesting does not install those (it uses brew cask install and apt-get), nor does can insert the required license to where it needs to be.

The following C/C++ macros was not displayed correctly until v3083 (linux x86_64) was released:

#define max(a, b) ((a) > (b) ? (a) : (b))
#define sign(a) (((a) > 0) - ((a) < 0))

However, the bug was introduced back in v3092, where the variables “a, b” is not italic (using default scheme).

UnitTesting is updated to support testing syntax_test files on CIs. See: https://github.com/randy3k/UnitTesting-example/tree/syntax