sublimehq / packages Goto Github PK

Marking reserved keywords should be disabled when we're marking ruby hash keys.

Have a problem with javascript scope,
in first line, scope of /class="\s*"/ is storage.type.js
but it should be string.regexp.js

var test = [
    // source.js storage.type.js 
    [/class="\s*"/]
    // source.js string.regexp.js 
    [
        /class="\*s"/
    ]
];

On OS X (10.10.3) I see the Go package at /Applications/Sublime Text.app/Contents/MacOS/Packages/Go.sublime-package, but within the editor I get the error message:

Error loading syntax file "Packages/Go/Go.tmLanguage": Unable to open Packages/Go/Go.tmLanguage.

This originally happened on an auto-update but persists after a reinstallation.

When I manually clone the packages repository and move/link the Go package (per the "Installation" instructions), thing work immediately.

• Can not highlight the regex end punctuation (the second slash in a regex)
• require_relative keyword is not detected
• Regex punctuation is marked wrongly as arithmetic operator. regex is not marked correctly again
• fail keyword is not detected
• Closing %> punctuations in erbs do not have punctuation scope, while the begin counterpart of it does
  

Does someone notice this problem?

In JavaScript/Object-Method.sublime-snippet, it uses :f as tab trigger. But once I type the letter f, other snippets (like for, function) are triggered.

I have to type esc first, then tab. Seems a little stupid.

I hope you can integrate tagging commits in this repo in the build workflow for ST (or do it manually, maybe) so that we can more easily check which file versions and changes were shipped in a certain release. This might be useful for you as well.

The language file for PHP doesn't seem to support the "new" bracket syntax for arrays introduced on PHP 5.4 (http://php.net/manual/en/migration54.new-features.php).

Fortunately, the colouring still mostly works anyway; except when a function argument is typehinted.

Issue

I've created a Pull Request with a fix for it

#97

Thanks for your time.

Hello Jon,

will there be something like *.hidden-sublime-syntax files? With the old TextMate files you could hide syntax files from the menu.

Using base16.monokai-dark color scheme, I see the following if I create a Go source file as such:

    //  var userKey key = 0
    //  func NewContext(ctx context.Context, u *User) context.Context {

If I add a package declaration to the file, as such:

package test

//  var userKey key = 0
//  func NewContext(ctx context.Context, u *User) context.Context {

I see this:

Right now, the html_completion.py file is mapping attributes to tags in a pretty crude manner (have a look).

I was thinking about saving the global attributes (see Mozilla Developer Network) that are common to all HTML elements as a list and adding them to all available tags.

global_attributes = ['accesskey', 'class', 'contenteditable', 'contextmenu', 'dir', 'hidden', 'id', 'lang', 'style', 'tabindex', 'title', 'translate']

I have a few questions about this.

1. Do you want this?
2. Can we assume that the global event handler attributes listed on the MDN page are common to all HTML elements as well?
3. Should attributes marked as obsolete API (such as bgcolor) be removed from the existing map?

Just a quick reminder that there is no license included in this repo, nor in any file afaik. This is quite an issue, since it legally limits us to only use github to refer to this code, or host it basically, and host modifcations of it, because you granted this right to github when you first pushed the repo. Basically, we can fork it and change our forks. I think.

Disclaimer: not license expert!

There might also be concerns with the .tmLanguage files you likely aquired from other sources that have no license attached to them. While most casual programmers don't care about one or another license, Sublime Text being a commercial and proprietary product and potentially violating licenses is a lot more concerning. I'm just raising awareness on this issue.

Some packages contain quite a few snippets, which creates a lot of noise in the package folder. I propose to move all snippets, or if they exceed a certain threshold (e.g. 4), to a new subdirectory called "Snippets".

This is really a broader version of #8, extending it to the whole package. The discussion there was headed this way and this is really a topic that deserves a separate issue of it's own. So, here it is.

The idea is that Packages in Sublime Text should be arranged in a standard way which may be optionally/partially enforced, like in other text-editors like TextMate 2 or Atom.

Since having too many files in the root directory of the Package creates a lot of noise, the various types of files should be moved into sub-directories in the package. While reducing noise in the root directory, it also makes the Package arrangement feel more organized.

Things worth more discussion (IMO):
Some initial questions regarding the structure:

• Is there a need for a "/tests" directory?
  Can tests for the Python code be placed in "/lib/tests" and syntax tests be placed in "/syntaxes/tests" instead?
• How many .py files should be there in the root package directory?
  Should it be only one, with the same name as Package ({name}/{name}.py) and it should include everything that it wishes Sublime Text (and other plugins?) to know about...
• Naming scheme for the sub-folders.
  Should they be CamelCase or snake_case or hypenated-names?

/cc @Jappen @FichteFoll @aziz @jbrooksuk @gerardroche @sublimehq

Initial Draft

(Based on @jrappen's original suggestion)

    /build
        /linux
            *
        /osx
            *
        /windows
            *.exe
        *.sublime-build
    /color-schemes
        *.tmTheme
        *.hidden-tmTheme
    /commands
        *.sublime-commands
    /keymaps
        *.sublime-keymap
    /lib
        *.py
    /macros
        *.sublime-macro
        *.tmMacro
    /menus
        *.sublime-menu
    /messages
        install.txt
        *.txt
    /metadata
        *.tmPreferences
    /mousemaps
        *.sublime-mousemap
    /settings
        *.sublime-settings
    /snippets
        *.sublime-completions
        *.sublime-snippet
    /syntaxes
        *.tmLanguage
        *.hidden-tmLanguage
        *.sublime-syntax
    /tests
        *.*
    /templates
        *.*
    /themes
        *.sublime-theme
    .gitignore
    .gitattributes
    .no-sublime-package
    *.py
    CHANGELOG.md
    CONTRIBUTING.md
    LICENSE.md
    README.md

In the HTML syntax currently the scopes source.js.embedded.html and source.css.embedded.html are being placed on the <script> and <style> tags and their contents respectively. These scopes, in reality, should be placed within the tags, as this is the embedded JavaScript and CSS.

Thanks for your help and time!

While cleaning up the empty elements (PR #101), I noticed a lot of elements and attributes in html_completions.py that are deprecated/obsolete in HTML 4.01 and/or HTML 5.

• Should these be removed?
• Is there any reason to keep them?

This code highlights incorrectly in Sublime Text 3 (build 3095)

class X
{
    void Run([Usage("help text")] int x, int y)
    {
    }
}

• Is there a reason, why Color Scheme - Default, Default, Language - English, Theme - Default, Vintage are missing from this repo?
• Will you accept people adding new language packages to the current ones?
• Can we add new packages that include executables such as linters, which require not being packed into a *.sublime-package? If so, do we mark them with a .no-sublime-package file as required by PackageControl?

Sample

@echo off
REM set args=%option-args:"=%

@echo on

somecommand -someStrginArg "syntax"
echo "string"

Github preview shows the same behavior.

for example, a piece of code:

- match: '(?<!\.)[_$a-zA-Z][$\w]*\s*(?=[\[\.])'
  scope: variable.other.object.js
  captures:
    1: variable.other.object.js
- match: '(?<=\.)\s*[_$a-zA-Z][$\w]*'
  scope: meta.property.object.js
  captures:
    2: variable.other.property.js

Capturing parentheses do not.

Applying different indent styles

Should be possible by using a *.tmPreferences metadata file that holds whitespace settings that are for example set to either:

⚠️ You'll need unix line endings, otherwise this messes up.

<key>shellVariables</key>
<array>
    <dict>
        <key>name</key><string>SPACE_OR_NEWLINE</string>
        <key>value</key><string><![CDATA[
]]></string>
    </dict>
</array>

or

<key>shellVariables</key>
<array>
    <dict>
        <key>name</key><string>SPACE_OR_NEWLINE</string>
        <key>value</key><string><![CDATA[ ]]></string>
    </dict>
</array>

and then used by snippets or completions like (⚠️ beware it's ${SPACE_OR_NEWLINE} not $SPACE_OR_NEWLINE in this particular case):

    { "trigger": "my_class\tclass", "contents": "my_class()${SPACE_OR_NEWLINE}{\n\t${1:first line}\n\t${2:second line}\n}" }

I already merged (most) snippet files into completions file for easier handling in #128. I could add some commits or open a new PR if this is desired. As far as my understanding goes, this would need three settings for:

• in between class and first line
• in the indented block between lines like first line and second line
• in between second line and the end

in the example above.

I'd be willing to do this for all languages, however I'd like to have a basic structure set first as well as a list of styles that should be included.

Currently in my test, to set the file icon for a .php file which starts with <?php, we need to use the scope embedding.php rather than source.php.

Will this be changed back to source.php or just use source.php, embedding.php for the icon settings in the future?

The built in JavaScript highlighter does a poor job at highlighting and given the rapid change we are seeing in the language right now, it would be worth making one of the better ones available by default.

One of these:

https://github.com/bathos/Ecmascript-Sublime (built on new syntax highlighter)

https://github.com/Benvie/JavaScriptNext.tmLanguage (most poeple use)

https://github.com/babel/babel-sublime (new, has JSX support)

According to the Stack Overflow survey, Sublime is by far the most popular editor for front end developers, so it would be really nice to start them off with a proper syntax highlighter that will work as everyone starts to use ES6.

On my sublime text 2 Matlab keywords like classdef or properties do not get highlighted.
For example in Matlab you can define object properties this way:

properties (SetAccess = private, GetAccess = public)
    someproperty
end

This is not highlighted in my ST (you can see that GitHub matlab highlighter is also unaware of that :) )
If this is not supported in ST - I would love to help, but unfortunatelly I know nothing about how syntax highlighting is defined in ST...

Now that I'm using the new ShellScript syntax my bash files are full of keywords.
Not everything is a keyword. I want to differentiate between shell keyword, shell builtin and external commands

• LESS THAN
• MORE THAN

Not sure if this has already been reported.

Inline image links appear to be having issues with syntax highlighting. I tried the Markdown Extended which highlights correctly, but spell checking marks it wrong with either syntax option.

Hi Jon,

I'm currently using *.sublime-snippet files with variables which I set via a *.tmPreferences file. Could you add that functionality to the *.sublime-completions files as well or something similar?

That way I can merge many snippet files into one completions file which is easier for maintenance. Thanks for considering.

Compare the use of ${LSL_SPACE_OR_NEWLINE}:

• python file
• allman style
• k&r style
• snippets and completions

Problem

I have a problem with snippets. Some of them doesn't match my coding convention. For instance, in c++, i always write a space after parenthesis and put the begin bracket on the same line as the scope declaration. I also use space instead of tabs. Example, I write:

if (a > 5) {
    // spaces at begin of line
}

while the snippet write :

if (a > 5) {
    // tab at begin of line
}

Solution

• add the possibility to overload or deactivate default snippets.
• enforce the use of tabs in snippets definition and auto convert space in snippets definition in spaces according to the settings of the user.
• let the user define synthax for snippets. Example :

    <content><![CDATA[if (${1:/* condition */})
{
    ${0:/* code */}
}]]></content>

switch to :

    <content><![CDATA[if${block_open_parenthesis}${1:/* condition */}${blick_close_parenthesis}${block_open_bracket}
    ${0:/* code */}
${block_close_bracket}]]></content>

We could set block_open_bracket to \n{\n or {\n according to our taste.

• it would be great to have the abillity to create language specific option. For instance, I use tabs in c++ and space for rust and python.

Containing scope seems to be this one:

Many keywords in D are not recognized by the default D syntax highlighter and are displayed as regular text. Here is a list of all of the keywords that I have encountered that are not recognized:

• string
• shared
• __gshared
• ref
• immutable
• @safe
• @Property
• @trusted
• @System
• @nogc
• pure
• nothrow
• assert

While the last one is technically a function, the Python highlighter recognizes the assert statement and it would be nice if it was in D as well.

Also, it does not recognize long literals like 1_000_000_000 as numbers.

I investigated into sublimehq/sublime_text#935 and fixed it, while also fixing an issue with modules remaining in sys.modules even if the import failed, which I discovered in the process.

For the cause of the bug, please read my (lengthy) comment at sublimehq/sublime_text#935 (comment).

I figured this was the best place to suggest this patch, even though the repo only contains "non-core packages".

Changes

1. Create empty parent packages if no __init__.py exists in an override package that didn't exist in the zipfile.
2. Refactored code a bit to more easily catch any exception when loading a module and remove the module from sys.modules if something went wrong. Remove only if the module wasn't there previously however. See the blockquote section of PEP 0302, specification part 1.

Other Remarks

1. self.contents and self.packages are initialized with a few empty string because the ZipLoader is also triggered for the very base module, which is just the package name, and the "key lookup" resolves to looking for the empty string. This looks ugly at first sight, but is required to override the base-package's contents with the contents of __init__.py. Problem: This only happens if __init__.py is overidden (and exists as a file) but not if it is included in the zipfile, since it is explicitly excluded from that case.

2. Even though __init__.py is loaded by normal Python import mechanics already, most notably if a zipfile does not exist, it is still considered a plugin interfacing file and loaded again from sublime_plugin.reload_module. This causes __init__.py to be run twice, iff a .sublime-package does not exist or it exists and __init__.py is overridden.
   Interestingly, __path__ is not set when __init__ .py is loaded a second ot n-th time via sublime_plugin.reload_module and causes a NameError.
   Example code:

   print("we loaded with", __loader__)
   print(__name__, __package__, __path__)

3. I hope my "agressive" commenting does not violate the file's no-comment policy. ;)

Edit: After taking a look at importlib.util.module_for_loader_wrapper and verifying that I'm doing the sys.modules deletion correctly, I'm not sure if we need to set mod.__initializing__. It says something about "otherwise an optimization shortcut in import.c becomes wrong".

Invoking importlib._bootstrap._call_with_frames_removed might also be a (hacky) consideration, referring to the importlib._bootstrap._LoaderBasics._load_module prototype.

Diff

--- C:\Program Files\Sublime Text 3\sublime_plugin.py  Fri Jul 10 17:40:44 2015
+++ C:\Program Files\Sublime Text 3\sublime_plugin.py  Fri Jul 17 05:24:05 2015
@@ -589,7 +589,8 @@
         self.zippath = zippath
         self.name = os.path.splitext(os.path.basename(zippath))[0]

-        self.contents = {"":""}
+        # Initialized for the Package's base module
+        self.contents = {"": ""}
         self.packages = {""}

         z = zipfile.ZipFile(zippath, 'r')
@@ -601,7 +602,7 @@
                 continue

             paths = base.split('/')
-            if len(paths) > 0 and paths[len(paths) - 1] == "__init__":
+            if len(paths) > 0 and paths[-1] == "__init__":
                 paths.pop()
                 self.packages.add('.'.join(paths))

@@ -611,6 +612,7 @@
                 print(f, "in", zippath, "is not utf-8 encoded, unable to load plugin")
                 continue

+            # Create empty 'parent' modules if they didn't exist
             while len(paths) > 1:
                 paths.pop()
                 parent = '.'.join(paths)
@@ -621,7 +623,7 @@
         z.close()

     def has(self, fullname):
-        key = '.'.join(fullname.split('.')[1:])
+        key = fullname.partition('.')[2]
         if key in self.contents:
             return True

@@ -635,48 +637,76 @@

         return False

-    def load_module(self, fullname):
-        if fullname in sys.modules:
-            mod = sys.modules[fullname]
-        else:
-            mod = sys.modules.setdefault(fullname, imp.new_module(fullname))
-
-        mod.__file__ = self.zippath + "/" + fullname
-        mod.__name__ = fullname
-        mod.__path__ = [self.zippath]
-        mod.__loader__ = self
-
-        key = '.'.join(fullname.split('.')[1:])
-
+    def get_source(self, fullname):
+        source, source_path, is_pkg = None, None, False
+
+        # Look for fullname in the read zipfile
+        key = fullname.partition('.')[2]
         if key in self.contents:
             source = self.contents[key]
             source_path = key + " in " + self.zippath

         is_pkg = key in self.packages

-        try:
-            override_file = os.path.join(override_path, os.sep.join(fullname.split('.')) + '.py')
-            override_package_init = os.path.join(os.path.join(override_path, os.sep.join(fullname.split('.'))), '__init__.py')
-
+        # Check if fullname has been overridden
+        override_file = os.path.join(override_path, os.sep.join(fullname.split('.')) + '.py')
+        override_package = os.path.join(override_path, os.sep.join(fullname.split('.')))
+        override_package_init = os.path.join(override_package, '__init__.py')
+
+        try:
             if os.path.isfile(override_file):
                 with open(override_file, 'r') as f:
                     source = f.read()
                     source_path = override_file
-            elif os.path.isfile(override_package_init):
-                with open(override_package_init, 'r') as f:
-                    source = f.read()
+
+            elif os.path.isdir(override_package):
+                is_pkg = True
+                if os.path.isfile(override_package_init):
                     source_path = override_package_init
-                    is_pkg = True
-        except:
-            pass
-
-        if is_pkg:
-            mod.__package__ = mod.__name__
+                    with open(override_package_init, 'r') as f:
+                        source = f.read()
+                elif source is None:
+                    # Create an empty 'parent' module
+                    source = ""
+                    source_path = override_package  # will hardly matter
+        except OSError as e:
+            raise ImportError("'%s' module could not be read: %s" % (fullname, e.args)) from None
+
+        if source is None:
+            # This can only happen if '.has' returned True earlier
+            # (which it shouldn't), but better be safe
+            raise ImportError("No module named '%s'" % fullname)
+
+        return source, source_path, is_pkg
+
+    def load_module(self, fullname):
+        if fullname in sys.modules:
+            mod = sys.modules[fullname]
+            new_mod = False
         else:
-            mod.__package__ = fullname.rpartition('.')[0]
-
-        exec(compile(source, source_path, 'exec'), mod.__dict__)
-        return mod
+            mod = sys.modules.setdefault(fullname, imp.new_module(fullname))
+            new_mod = True
+
+            mod.__file__ = self.zippath + "/" + fullname
+            mod.__name__ = fullname
+            mod.__path__ = [self.zippath]
+            mod.__loader__ = self
+
+        # Absolutely make sure to remove from sys.modules if anything fails
+        try:
+            source, source_path, is_pkg = self.get_source(fullname)
+
+            if is_pkg:
+                mod.__package__ = mod.__name__
+            else:
+                mod.__package__ = fullname.rpartition('.')[0]
+
+            exec(compile(source, source_path, 'exec'), mod.__dict__)
+            return mod
+        except:
+            if new_mod:
+                del sys.modules[fullname]
+            raise


 override_path = None

For those who aren't aware, I've been maintaining Python Improved for the past few years (with a lot of help and discussion from @FichteFoll and @facelessuser, among many others), and it's become pretty popular on Package Control. It started out as a side project to fix a couple of glaring issues with the syntax that ships with Sublime, but as I became more familiar with it and began rearranging and improving/consolidating/expanding things I found more and more issues to fix and features to add, and now it has definitely taken on a life of its own. Its development has been in parallel with my Neon Color Scheme, which I started soon after I discovered Sublime in the first place and dove deep into syntax highlighting and customization, as well as the Python language itself. From the start I've always entertained the thought that Sublime's packages would be open-sourced and I could merge my improvements back in to help everyone, not just those that have found my package.

At any rate, I was wondering if there was any interest in either merging Python Improved with the default Python syntax hosted here, or really overhauling the current Python definition, taking work from PI as well as some other alternate Python syntaxes, @petervaro's Python 3 being first in my mind. (On a side note, Py3 is licensed under the GPL, while PI is under the MIT License, so that may be an issue.) The designs are different - I've tried to keep PI in as similar a vein as the original as far as naming scopes goes, whilst Py3 uses an entirely different naming scheme. PI has been designed as a standalone file, coding in a .YAML-tmLanguage file, then converting it to an old-fashioned .tmLanguage PLIST using AAAPackageDev, but Peter has built Py3 and his Cython syntax using Python itself - the various scopes and regexes are defined in dicts, then he puts the whole thing together with a build script. And, of course, PI works equally well with both versions 2 and 3 of the language, whilst Py3 is 3-specific, if you couldn't tell. 😄 Different strokes for different folks.

I'm preparing for a new release of PI that, among other things, should support Unicode identifiers (source is in the unicode branch). I haven't exhaustively tested it yet, but I'm writing a script to choose random characters within and outside the ranges specified in PEP-3131 (taken from this resource), put them into varying-length "words", then write them to a file for testing in Sublime. It seems to work well enough with the characters I've picked so far from Windows' CharMap. I think this will be a real ground-breaking improvement that I'd love the default Python syntax to have as well. There are a bunch of other improvements I'd like to contribute as well, including support for function annotations, binary literals, expanded matching of all *Exception and *Error identifiers, lots of changes to function and class definitions, rearrangement of keywords, consistent highlighting of built-in functions and types, proper highlighting of escape sequences in strings, removal of SQL keyword matching (it's incomplete, random, distracting, and buggy), and more. There may some stuff in PI that possibly doesn't need to be in the main Python def, like support for highlighting the IPython In and Out fields in SublimeREPL, and maybe the expanded comment highlighting for key words like BUG, FIXME, XXX, and TODO, but that can be debated elsewhere. Like I mentioned, PI is currently written in AAAPackageDev's version of YAML, but I've been meaning to start playing around with the .sublime-syntax format, so here's my chance! Somebody just needs to write a syntax definition for it so I can highlight it properly...

So here's what I'm looking for: first and foremost, feedback on whether or not you think this is a good idea, and if you do, ideas on implementing it. Do we build a more-or-less "finished product" behind the scenes (as a branch of this repo, a new repo under @sublimehq, a new repo under someone else (I'll volunteer), a branch of PI, or something else altogether) and then submit it all as one gigantic PR, or piecemeal submit PRs to this repo and have Jon (or anybody else with commit privileges here - who exactly is that, anyway?) apply them live?

Personally, I think the best option would be to have a Python-specific branch of this repo or a new repo altogether, so the entire history can be tracked. I'm completely willing to host one, but I may not be the most objective person to decide on the quality and necessity of the PRs (although I'm a scientist IRL, so I try to be as objective as possible). More importantly, since this is a hobby and I'm not a full-time programmer, there may be times when work/family/life interferes and I'm not able to contribute for a bit. I'd certainly support having it here if the committers are willing to stay ... umm ... committed and not let things sit around for days and weeks - IMO FichteFoll has done an excellent job with the ST Issues trackers, so if s/he is interested I'd definitely nominate him/her.

So, thoughts? Suggestions? Issues?

Is it just me?

Something happen in the last weeks making it harder to read JavaScript properly.

Two weeks ago (installed JavaScript package from version 3a0cf88):

Current (latest one that bundles with Sublime):

This sudden explosion of green mutilates the Monokai theme as we knew it. Due to the change being in the grammar itself, there is no longer a sufficient distinction in the symbols. Making it hard (if not impossible) for theme developers to fix this. It has to be addressed in the JavaScript syntax file.

While the explosion of method symbols (green in Monokai) seems undesirable. It is however nice that object literal colons and dot notation are now recognised as distinct grammar. Though it's odd that they are highlighted as integers (purple in Monokai) instead of operators (red in Monokai).

Atom also started to recognise colons recently, but colors them red (as one would expect). Here is Atom v1.0.0 for comparison, much more in line with the original Monokai scheme:

As discussed in #22, when typing /** all subsequent code turns red, because DocBlock requires lines start with asterisks, and at that moment they don't.

Is that really necessary? It's perfectly valid PHP to have a comment starting /** with anything inside it. And the blocks of dark red appearing/disappearing is quite ugly UX to be honest.

It would be nice to see systemd services syntax highlighting and linting in Sublime Text:
https://atom.io/packages/language-systemd

I've been using the dev build for a while now so I could use the .sublime_syntax style files, and I've created a custom JavaScript language definition that highlights ES6 and JSX correctly, which the current bundled JavaScript language definition does not. Is it a goal for the bundled JS definition to include these? I was considering creating a PR into it, but wasn't sure if that is desired.

Note how << std::endl is being interpreted as a string, not an integer literal.

PR #117 (from me, today) introduces a problem with try-with-resource syntax:

That PR attempts to solve a problem with out-of-method assignment code being incorrectly parsed as a method definition. In so doing it creates a new meta-scope of meta.assignment.rhs.java which should encompass the expression to the right of the equals sign in an assignment.

There's a situation where this can go wrong. First discovered with respect to try-with-resource declarations, where the last, or only, declaration is not terminated by a semicolon. Thus:

try (Stream<String> lines = Files.lines(path)) {
    lines.forEach(System.out::println);
}

It can also affect for-loops, but only if the final clause has an assignment. This trips it:

for (int i = 0; i < 10; i+=2) {
    System.out.println(i);
}

Ideally we'd want a reliable way of "consuming" an expression without needing a terminator, but that may not be doable in regex. If the problem can be confined to try (...) and for (...) that might offer some more restricted-scope solutions.

Vagrant ship the filename Vagrantfile which has ruby syntax. But while opening in sublime no synatx is set. Please have it offically set.

As the image shows below, there are a number of issues with the Go syntax highlighting provided by this package (and inherited from GoSublime?):

• Grave accent ``` strings do not correctly highlight for formatting arguments like %s
• Normal " strings do not syntax highlight correctly for numbered formatting arguments like %[1]s
• Primitives inside of function definition arguments or returns do not syntax highlight
• Function definitions that take more than one line cause the function name to stop highlighting
• Type definitions for function types cause the type keyword to stop highlighting
• Function definitions following a type definition of a function type do not highlight the func keyword or the function name
  

Since this morning any syntax scheme I choose returns this error.

Apparent recursion within a with_prototype action: 25000 context sanity limit hit

When using double quotes (") to expand a variable in the default setting for a environment variable, syntax highlighting fails for the rest of the file:

question mark is black.

Espresso Soda.tmTheme fragment for php start/end tags:

<dict>
  <key>name</key>
  <string>PHP Tags</string>
  <key>scope</key>
  <string>punctuation.section.embedded.begin.php, punctuation.section.embedded.end.php</string>
  <key>settings</key>
  <dict>
    <key>fontStyle</key>
    <string>bold</string>
    <key>foreground</key>
    <string>#d5474f</string>
  </dict>
</dict>

Sublime Text version: 3, DevChannel, Build 3095

For all my projects i used .php.inc extension. Current version of Sublime doesn't support this extension.
See for more information about this extension: http://stackoverflow.com/questions/7129842/what-is-inc-and-why-to-use-it

Consider the following code:

reg = re.compile(r'(\s*[([]?\s*H\s*[\|/-]?\s*F\s*[)\]]?)?$', re.I)

Seems simple enough, a regular expression defined in a raw string literal, containing a bunch of parens and brackets and stuff. Github properly ends the string at the closing single quote '. However, earlier versions of Sublime's Python syntax, and my own Python Improved syntax, have had issues with finding the closing paren ) in capture groups, and the closing string marker (single single or double quotes, or triple single or double quotes). Here's an example using the Build 3083 .tmLanguage definition (Python Improved looks identical):

Here is an example using Build 3095 and the new .sublime-syntax format:

You can see how the regex scopes in the upper example are never terminated. I encourage you to play around with the sequence using the 3083 definition or Python Improved, and see what characters are required to close the regex.

I took both images using Build 3095 on OS X, but I and others have been able to replicate it with previous releases and on Windows and Ubuntu as well, so I'm pretty sure it's not a platform or build thing. I've translated both PythonImproved.tmLanguage and Build 3083's Python.tmLanguage into sublime-syntax format, with no luck. Since there's no backwards conversion tool, I can't translate Build 3095's Python.sublime-syntax into either tmLanguage, YAML-tmLanguage, or JSON-tmLanguage formats to see what the difference is.

I'm dreading having to go through the Python Improved and original Python sublime-syntax files line by line and regex by regex to see what's different (answer: a lot) and relevant. I'm assuming it has something to do with how quotes and/or parentheses/brackets/braces are matched, but I'm not sure. Regular Expressions (Python).tmLanguage has also changed to sublime-syntax, so I don't know.

So, I have two questions for whoever did the conversion from tmLanguage to sublime-syntax: what did you do differently to make regexes like this work? Also (slightly less important, but interesting all the same): How did you scope the content of regexes in raw string literals as source.regexp.python when it wasn't before?

I am _extremely_ interested in learning the answers to those questions, especially the first. Thanks!

PS: While we're at it, a third, somewhat related question: why not expand from AAAPackageDev's YAML-tmLanguage instead of making your own, incompatible format? Just wondering, because I have great syntax highlighting of the regexes in .YAML-tmLanguage files (thanks to my Neon Color Scheme), but everything in .sublime-syntax files is just boring strings. Also, it's a format developers already know (hopefully) so there isn't as steep of a learning curve. Maybe there were just too many features you wanted to put into sublime-syntax that it wasn't worth it. I'm trying to adapt the YAML-tmLanguage syntax def to sublime-syntax, but that'll take a while. Anyways, thanks again!

In TeX.sublime-syntax line 41 there's this include:

- include: $top_level_main

Is this $top_level_main simply a bug or does it mean something?

A quick search showed that it's been used in other places as well.
namely: C, C++, Objective-C, D, LaTeX and TeX