Hi there… i just updated to 3091 but I`m having some crazy issues with the crawler
it is consuming 100% CPU and lots of memory…
will try to go back to 3088 for now, and wait for the fixes in any case thanks for the work !
Dev Build 3090
I have problems with bash and php syntax files :
no such context scope:source.scss#.string-single in Packages/ShellScript/Shell-Unix-Generic.tmLanguage
Error loading scope:source.php: Unable to find syntax file for scope source.php in Packages/PHP/PHP.sublime-syntax
I reinstalled the 3088 version, and have this message with php files :
Error loading syntax file "Packages/PHP/PHP.sublime-syntax": no such context scope:source.json at line 307 column 24
The solution is to delete the cache dir for php (i.e., “~/.config/sublime-text-3/Cache/PHP” with Linux)
True… i had to remove all contents of cache folder… but that is not really critical… as it only made sublime restart a bit slower once
[quote=“jps”]3091 is out now addressing the above issues.
@facelessuser: the primary change in 3090 was changing the way syntax files are included, it’s already what you suggest[/quote]
Sorry, I was mistaking the some of the other issues as this one. Thanks for the change! I just upgraded to 3090 and was having some problems and thought they were related.
I’d avoid 3091 also. It already crashed several times this morning.
First time that I’m having issues with a version of Sublime and I’ve been on dev builds for quite a while now.
After upgrading to 3091 I can’t seem to open .php files anymore. As soon as I try to open a php file this happens:
Clearing the cache didn’t fix it, unfortunately. And reverting to 3088 screws up my php syntax highlighting. Right now I’m using 3090.
Any tips? Thanks in advance!
[quote=“appel”]
Clearing the cache didn’t fix it, unfortunately. And reverting to 3088 screws up my php syntax highlighting. Right now I’m using 3090.
Any tips? Thanks in advance![/quote]
I reverted to 3088 and then cleared the cache files for PHP, that fixed the syntax highlighting.
[quote=“appel”]After upgrading to 3091 I can’t seem to open .php files anymore. As soon as I try to open a php file this happens:
Clearing the cache didn’t fix it, unfortunately. And reverting to 3088 screws up my php syntax highlighting. Right now I’m using 3090.
Any tips? Thanks in advance![/quote]
I cleared this folder C:\Users\<$UserName$>\AppData\Local\Sublime Text 3
and re-installed.
I’m unable to replicate any of the issues with PHP in initial testing. For those who have been seeing issues:
-
Do you have any custom syntax definitions for PHP, HTML, JavaScript or CSS?
-
If you are running on Windows, do you see the same issues using an unmodified portable version?
Having same problem with the latest build, sublimetext hung all the time, once I open the console and I got this message before it hung:
Error loading scope:source.php: Unable to find syntax file for scope source.php
The point is I don’t have PHP files in my project.
Upgrade to 3091 has the same issue, revert to 3088 got it fixed. But it looks like syntax files were messed, trying to fix them now.
As previously mentioned, the hanging with php is only present if you are running SublimeLinter. Disabling (ignoring) this package fixes it.
Actually this happened to me in 3090, but fixed in 3091.
Now my php lints but I have no idea why.
[quote=“jps”]I’m unable to replicate any of the issues with PHP in initial testing. For those who have been seeing issues:
-
Do you have any custom syntax definitions for PHP, HTML, JavaScript or CSS?
-
If you are running on Windows, do you see the same issues using an unmodified portable version?[/quote]
Here is a custom PHP syntax to test with: github.com/gerardroche/sublime-php-grammar
In ST3 it will auto disable the default PHP package.
When cloning into the packages directory clone into a directory named “php-grammar”. That’s all there is to the installation. See Installation guide: github.com/gerardroche/sublime- … stallation. e.g.
git clone https://github.com/gerardroche/sublime-php-grammar.git ~/.config/sublime-text-3/Packages/php-grammar
Short version: SublimeLinter installs its own version of HTML.tmLanguage, which takes precedence over the new HTML syntax definition. Because this is based on the old HTML syntax definition, it includes PHP. However, as it doesn’t also override PHP, it picks up the new version of PHP, which includes HTML. Sublime Text, perhaps understandably, doesn’t handle this mutual recursion nicely. I’ll fix that for 3092.
The larger question is what to do with the SublimeLinter provided HTML.tmLanguage. I suspect I’ll have to put in some hard coded logic to make them get ignored. This will require SublimeLinter to be updated for it to work properly, but that’s inevitable with the updated syntax definitions.
[quote=“jps”]Short version: SublimeLinter installs its own version of HTML.tmLanguage, which takes precedence over the new HTML syntax definition. Because this is based on the old HTML syntax definition, it includes PHP. However, as it doesn’t also override PHP, it picks up the new version of PHP, which includes HTML. Sublime Text, perhaps understandably, doesn’t handle this mutual recursion nicely. I’ll fix that for 3092.
The larger question is what to do with the SublimeLinter provided HTML.tmLanguage. I suspect I’ll have to put in some hard coded logic to make them get ignored. This will require SublimeLinter to be updated for it to work properly, but that’s inevitable with the updated syntax definitions.[/quote]
I think there are more plugins using custom syntaxes and referencing tmLanguage syntaxes than you might think. This will break a lot of stuff and make a lot of people unhappy.
If you know of any, I’d like to know what they are.
The only problematic scenario should be replacing HTML or PHP: replacing any other syntax should be ok, and replacing both should be ok, but replacing just one isn’t.
Maybe preventing a tmLanguage to override a sublime-syntax would be the way to go: this basically forces all plugin that includes their own syntax to be updated with the new syntax and would prevent any issue like that. Since there is a tool to convert to the new syntax it’s not like this is a big work for the plugin devs, and it’s something that they should do eventually.
I don’t have the indexing problem since i disabled one of the three PHP languages I have installed, but I have no idea which is which…
So yeah, I’m pretty sure it’s a problem with overriding packages…
Edit:
- I removed PHP Companion plugin and i got rid of one PHP version. The problem was still present.
- I tried to remove my own version of PHP, but the problem was still present (the index freeze) and the editor freeze when i’m trying to set syntax as PHP
2.1) disabling built in PHP and enabling a 3rd party (either mine or php companion) won’t crash the editor anymore but i don’t have right syntax highlight either (but if i’m setting the syntax as HTML is all good) - Sublime portable is ok, so it’s pretty obvious that there is a problem with a package that i have installed
[quote=“jps”]Short version: SublimeLinter installs its own version of HTML.tmLanguage, which takes precedence over the new HTML syntax definition. Because this is based on the old HTML syntax definition, it includes PHP. However, as it doesn’t also override PHP, it picks up the new version of PHP, which includes HTML. Sublime Text, perhaps understandably, doesn’t handle this mutual recursion nicely. I’ll fix that for 3092.
The larger question is what to do with the SublimeLinter provided HTML.tmLanguage. I suspect I’ll have to put in some hard coded logic to make them get ignored. This will require SublimeLinter to be updated for it to work properly, but that’s inevitable with the updated syntax definitions.[/quote]
[quote=“jps”]
If you know of any, I’d like to know what they are.
The only problematic scenario should be replacing HTML or PHP: replacing any other syntax should be ok, and replacing both should be ok, but replacing just one isn’t.[/quote]
Maybe I’ve misunderstood. Hardcoded logic specifically for SublimeLinter? The reason SublimeLinter HTML.tmLanguage should be ignored is because of recursion? If this is the only reason, then if recursion is detected, bail out, ignore/exclude the troublesome syntax, and log an error message to the console for the user. possibly even disable the plugin and display a dialog to the user about the package having issues. Because recursion will occur for any syntax with a dependency on another when one or the other changes in an unexpected way that introduces the recursion. There is no package dependency management so syntaxes are at the mercy of their dependencies.