[.sublime-syntax, syntax_test] tabs in code throw off tests; tests basically require regular spaces.

[abathur]

I identified this elsewhere for a new syntax def I'm writing, but I've boiled it down to a simpler reproduction case here:

Follow these steps:

1. open/create a markdown (.md) file, go to Tools -> New Syntax from Markdown.tmLanguage
2. Save the .sublime-syntax that is opened in your Packages dir. I used Packages/Users/Markdown.sublime-syntax for mine.
3. Create a file with the following contents and save it (anywhere is fine, I think) with the name sublime_syntax_markdown.md:

// SYNTAX TEST "/Packages/User/Markdown.sublime-syntax"
    test
//  ^ meta.paragraph.markdown

1. Use your build command, and build as a Syntax Test

The above steps produce a result like this for me:

Packages/User/syntax_test_markdown.md:2:5: [meta.paragraph.markdown] does not match scope [text.plain]

The actual scopes I see at this position are: text.html.markdown meta.paragraph.markdown
The plausible followup (use tabs in the test defs instead of spaces) won't work; the build fails (interior tabs, please use spaces only). The other solution (converting tabs to spaces in the code) is an acceptable workaround in my case, but it seems inevitable that someone will eventually want to build tests for a syntax definition (.tsv?) where tabs are critical.

[FichteFoll]

Interesting use case. For normal cases, spaces are perfectly fine and preferrable, since they are fixed-width. However, I see how testing if the syntax also works with tabs is useful.

Do you have a proposal on how to tackle this? The issue is that the syntax test files are read from the file system (as they should), which means that ST does not know what your desired or used tab width is.

I'm thinking of a TABSIZE:4 argument-thing in the first line after <comment> SYNTAX TEST "...".

[abathur]

I'd been pondering adding some additional arguments to the declaration as a way around, myself, since even if it did have column information from the editor, it could vary for whoever is running the tests. I think a TABSIZE "argument" is a reasonable way to handle it.

It also seems like the <comment-token> <- <scope> form could be used with tabs preceding the comment token but still not allowed inside the test spec itself, but when I tried this (in my original case; I didn't repeat this effort on the reduced test case I submitted here) it complained about misaligned spacing, if I recall.

[abathur]

I also have a related but slightly OT question; I (along with one or two others) have been providing some feedback on the forums (in the build 3092 post) about the friction points for the syntax_tests we've been writing and what refinements might help.

I've been using the heuristic that it didn't seem reasonable to cause everyone involved the overhead associated with full feature/enhancement requests here on functionality that the cement didn't seem dry on yet when Jon might be able to consider and roll them in more quickly via discussion on the build posts as he's actively working on them. The issue here seemed less like a refinement.

Should we continue with those discussions on the forum, open enhancement requests here when we have concrete suggestions/problems, or both?

[FichteFoll]

I don't know, honestly. I usually prefer using this github tracker since it's better organized (open/close, tags) and I know pretty much most of the tickets since I tag them all, so it's easy to refer people to related issues or to spot duplicates. However, I do not know how much Jon looks into the tracker by himself. I know he follows links if you embed them in a forum post but aside of kari answering via email that he does indeed read the tracker occasionally, I haven't seen any sign of this from him.

[abathur]

Thanks. I think that helps. I'll keep posting suggestions there, and formalize/port a subset here when it becomes obvious development has moved along without covering them.