ST3 3157: Syntax Tests Problems

[tajmone]

I’m working on a new Syntax, currently I’ve only implemented a few syntax elements and they are working correctly — when I check the scopes wiht Ctrl-Alt-Shit-P they are as expected.

So I thought of creating some syntax_test_* files, but when I open the test files in the editor I always get this error message in a popup window:

Syntax tests do not work properly with tabs as indentation.
You MUST use spaces!

… even though the source files don’t contain any tabs. It seems that the problem is that the current settings in the IDE are t use tabs instead of spaces — even though in the syntax settings I’ve clearly defined it to use spaces instead of tabs, and that tabs should be 2 spaces, but it seems the settings are being ignored. I then have to manually set ST to use spaces instead of tabs, and the nagging error stops showing up.

I’m not sure the tests are actually working as they should — this is the first time I use syntax test files, and the documentation doesn’t dwelve too deeply into the topic. My impression is that the tests are not working.

When running the tests I always get:

Success: 0 assertions in 1 files passed
[Finished]

Does 0 assertions mean that no actual test was carried out?

This is my test file:

; SYNTAX TEST "Packages/PureBasic/PureBasic.sublime-syntax"
; <- source.purebasic

; A comment line
; <- punctuation.definition.comment
; ^ source.purebasic comment.line.purebasic

Debug "something" ; A comment following code
;                 ^ punctuation.definition.comment.purebasic
;                  ^^^ source.purebasic comment.line

Debug "something"
; <- punctuation.definition.comment

… where the last test is intentionally supposed to fail. I’ve tried many variations, but always get the same results (and the nagging error message).

[kingkeith]

Does 0 assertions mean that no actual test was carried out?

yes, it seems that although it found the syntax test file, it didn’t find any assertions. Your test file looks fine at a quick glance, so I’m not sure why it’s not working properly. Something that bit me recently was that the syntax definition’s filename’s casing didn’t match the syntax header line, and weird things ensued, perhaps it is the case here also?

[tajmone]

Thanks @kingkeith, your comment prompted me to look closer at the first line: it was the BOM!

I had forgetten that the native IDE of the language I’m creating a syntax for adds a BOM the source files.

So you’re right: it wasn’t finding the syntax file, not due to the file lettercasing (I’m under Windows, so casing it shouldn’t be an issue) but due to the BOM.

I think that it’s worth making a feature request for this: Sublime Text should be smart enough to detect and strip the BOM.
After all, many Windows application do add a BOM to UTF-8 source files — even if it’s not reccomended to do so it’s not wrong either, and many MS application do impose a BOM.

[tajmone]

Added feature request:

Add BOM Awareness for Syntax Test Files

As of ST3 3157, syntax test files with a BOM fail to work because the BOM prevents ST from correctly parsing the first line. See my post: Some languages' native IDEs do add a BOM when they save source files. The UTF-8 specification allows adding a BOM, even if it's discouraged. Adding a BOM check and stripping function shouldn't be problematic, and might solve lot's of issues when working with shared code where some contributors use IDEs which add a BOM. Also, it might be worth mentioni…

[kingkeith]

nice find my letter casing problem was on Windows actually - as ST is cross platform, it doesn’t necessarily behave in a case-insensitive manner on Windows. It was only on Linux when it acted like it couldn’t find my syntax definition at all that I realized what was going on.

[tajmone]

as ST is cross platform, it doesn’t necessarily behave in a case-insensitive manner on Windows.

Mhhh … if this behaviour only affect settings/packages then it’s good a thing; otherwise, in a more general working context I’d hope that ST on Windows isn’t picky about filenames case — at least not in projects.

On the one hand, case sensitiveness is a good reminder when it comes to cross platform collaboration, on the other hand it could lead to headackes for Windows users who can easily overlook this. I’m not sure what would the best behavior to expect.

Probably the best solution would be to allow users to customize in the settings how ST for Windows should handle file-names case-sensitivity, both globally and per-project. For example, in a MSVS project case sensitivity should be disabled at levels (packages, plugins, etc.), while on cross-platform project it would be better to turn it on, and to receive some warning of sorts if ST matches a file with different casing.