Dev Build 3092 is out now, which resolves the issues in 3091 exposed by some third party packages.

Two other relevant changes:

• All files named ‘HTML.tmLanguage’ are now deprecated and ignored. This is due to all of them being based off of the old HTML.tmLanguage: the correct way to include PHP and Ruby from HTML changed as of 3087. Any packages providing their own must now provide HTML.sublime-syntax instead, or better yet, don’t override the default version at all, and send in a patch. The shipped packages will be published on GitHub once the current series of changes settle down.
• Whenever there is a file Foo.tmLanguage and Foo.sublime-syntax, Foo.tmLanguage will be ignored entirely. This allows packages that provide syntax definitions to provide both tmLanguage and .sublime-syntax variants, for compatibility with older versions of Sublime Text.

3092 may cause issues with SublimeLinter, due to SublimeLinter’s custom HTML.tmLanguage file being ignored now. It seems to work in my basic testing, but it was far from comprehensive.

The sublime-php-grammar package will need to be updated now, to work in the same manner as the shipped PHP package: a top level PHP.sublime-syntax file should include HTML.sublime-syntax, using with_prototype to add support for ‘<?php ... ?>’ syntax.

The convert syntax command should allow to convert any .tmLanguage open in the current view. Currently the command requires the syntax to be enabled to convert it. This makes it easier to convert any .tmLanguage file.

\o/
so far it looks great… sublime used a little CPU on restart but that’s understandable as I think it was updating indexes and cache and it quickly stabilized!
Thanks for the update jps great work!

[quote=“jps”]
The sublime-php-grammar package will need to be updated now, to work in the same manner as the shipped PHP package: a top level PHP.sublime-syntax file should include HTML.sublime-syntax, using with_prototype to add support for ‘<?php ... ?>’ syntax.[/quote]

I’m getting bug reports for php-grammar on 3092 github.com/gerardroche/sublime- … r/issues/9.

The update you mention is just include HTML, it shouldn’t really cause errors like in bug report?

Is it possible to log more information about which package is causing the error loading the syntax?

error: Error loading syntax file “Packages/PHP/PHP.sublime-syntax”: Unable to read Packages/PHP/PHP.sublime-syntax

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