Sublime Forum

Dev Build 3108

#1

Dev Build 3018 is out now at https://www.sublimetext.com/3dev

1 Like
#2

My font_face is suddenly a proportional font?

2016-03-18_01.53.38.png2568×1410 161 KB

Edit: It also appears that plugin load order is entirely screwed.

Edit2: Attempting to run the regex compat build system on the yaml def I had symlinked to the Packages Folder resulted in this:

Traceback (most recent call last):
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 551, in run_
    return self.run(**args)
  File "run_syntax_tests in C:\Program Files\Sublime Text 3\Packages\Default.sublime-package", line 147, in run
  File "run_syntax_tests in C:\Program Files\Sublime Text 3\Packages\Default.sublime-package", line 289, in package_relative_path
  File "C:\Program Files\Sublime Text 3\sublime.py", line 140, in load_resource
    raise IOError("resource not found")
OSError: resource not found

Works in console, so probably bad path being constructed (forward vs. backward slashes?):

>>> sublime.find_resources("YAML.sublime-syntax")
['Packages/YAML/YAML.sublime-syntax']
>>> bool(sublime.load_resource(_[0]))
True
0 Likes
#3

hmmm i am using the cobalt2 theme from wes bos on osx. odd thing that happened after upgrading to 3108, sublime fell back to the default layout even that the preferences are still showing cobalt2 for color theme and theme. that happened before in previous dev builds but in that case sublime set back the color theme and theme preferences in the user settings. but this time it is still showing cobalt2 in the user preferences. the console isn’t showing anything cobalt2 related.

0 Likes
#4

Yep same here. I’m on material theme, and it’s not displaying correctly.

2016-03-18.png3840×2007 244 KB

0 Likes
#5

Unsurprisingly, I see the same problem with plugin load order. It makes for some interesting menu bars :smile:

0 Likes
#6

Thanks for the reports, 3109 is out now addressing this issue

2 Likes
#7

Thanks a lot for the fast fix :slightly_smiling:

0 Likes
#8

Thanks for the new Regex Compatibility Syntax Test Build Variant @jps, it’s very useful :slight_smile:

Is my understanding correct that the new regex engine will only be used if there are no incompatible regexs found in the syntax definition file?

I notice that the new engine currently has no support for any lookbehinds. Are there any plans to change this? The reason I ask, is I am wondering, is it worth it for me to try to re-write my regexs that use lookbehinds, so that I can run the performance tests against the new engine and compare it to the performance using the old engine and lookbehinds, to see which is better? If lookbehind support is potentially coming soon, then it would be a waste of my time to do so I think :wink:

0 Likes
#9

I’ve noticed that the new YAML highlighting shows an invalid scope (source.yaml invalid.illegal.unrecognized.yaml) on the first line of the template created by Tools -> Developer -> New Syntax.

EDIT: I can see from the spec that the version number should be separated from the %YAML by whitespace, so the syntax definition is correct, and the template generated from the new_syntax command is wrong.

I have logged the issue.

0 Likes
#10

It’ll be used for all the regexes it supports, with onigurama used as a fallback only for the unsupported ones.

If possible, it’s strongly preferable to only use regexes supported by the new regex engine: this guarantees efficient file loading and indexing. The new JavaScript syntax definition is an example of this.

Standard lookaheads are supported, but not lookbehinds nor backreferences. It’s very unlikely that support for these will be added.

1 Like
#11

Understood, thanks for the info :slightly_smiling: it looks like I will need to figure out how to refactor my syntax definitions to not use lookbehinds :wink: I will take a look at the JavaScript definition for inspiration :wink:

0 Likes
#12

In general to prevent lookbehinds you should try and consume the given token by an earlier rule.

So instead of (?<!::)foo to prevent matching foo after ::, instead consume :: and then push into a scope where foo is treated as normal text, or set to the appropriate scope name. Once you’ve matching an identifier following ::, you can pop back to the context you were in.

1 Like
#13

Thanks for the tip, that is really good advice and makes perfect sense :+1:

0 Likes
#14

3108 (then 3109) have arrived here (OS X). Every color scheme behaves badly with HTML. Here’s Monokai:

Pasted image741×414 44.3 KB

I haven’t checked other syntaxes.

Is it me or is it you? :wink:

0 Likes
#15

Can you post the contents of that file somewhere? Also, be sure you are using 3109. 3108 had a package loading issue.

0 Likes
#16

For people having troubles with themes - have you tried quitting sublime completely and then starting it again? I have not tried this build yet, but it helped me before when I had similar issues after upgrades.

0 Likes
#17

I followed the advice and am pleased to report that I have had great success! I had to get creative in how I thought about the contexts etc. and use some non-consuming lookaheads to decide when to pop some contexts so that the parent context can match etc. but overall it was a lot easier than I feared to rewrite my expressions without using any lookbehinds.

and the performance tests show it is much faster too, and even more positively, my entire syntax definitions match much more accurately and report on invalid characters better. Thanks once again for the advice, you have a very happy package developer here :+1:

2 Likes
#18

I would also offer this tip to other syntax definition writers: it can help you to work out which contexts are on the stack by temporarily setting a unique meta_scope for every context while you are developing and testing your syntax definition.

0 Likes
#19

Great to see that with @wbond coming to sublime text, sublime evolve more quickly !

1 Like
#20

Sure. Temporarily, it’s here:

https://drive.google.com/file/d/0B9yGBpYsyBLrb1VNR1lIQnJfQXM/view?usp=sharing

I see the problem, too: it’s an HTML file with an XHTML DOCTYPE with an XML processing structure above all that – as though it were going to be served as XML. Scope hunter tells me second and following words of most paragraphs are:

text.html.basic
meta.tag.preprocessor.xml.html
entity.other.attribute-name.html

Removing the XML processing instruction restores the editor’s idea of what the file really is.

0 Likes