Sublime Forum

**wbond** · November 3, 2017, 5:08pm

There shouldn’t be. I will have to dig into it some.

You will probably want your escape to be ^(?=\1) so that it is anchored to the beginning of the line. The backreferences will capture literal text, but not assertions like ^.

**ngppgn** · November 5, 2017, 4:27pm

Further question about embed: I know we can capture a group in the match that embeds and abckreference to it in the escape regex, but can we also bacreference to said capture group in the regexes defined within the embedded context? Because that would be really handy.

**kingkeith** · November 6, 2017, 4:19pm

I’m not sure if this is related to this report:

but I’ve noticed that ST’s hashed syntax highlighting treats each “token” as a separate entity, even when scoped the same (with the same match pattern even) as the adjacent text. i.e. a match pattern for . instead of .+. This can be most clearly seen with the example .sublime-color-scheme you provided with the find panel, typing a literal like testing123:

on a related note, it would be great if plugins that query for scope information could find out the extent of a scope that was applied from one match pattern, for example to distinguish that .. in regex syntax is actually two tokens of . and not one token of .., or that \s\w is one token of \s and one of \w, and not one of \s\w which is what view.find_by_selector('keyword.control.character-class.regexp') or view.extract_scope would have you believe - I guess a separate API would be needed for this for backwards compatibility reasons.

**wbond** · November 6, 2017, 6:54pm

No, unfortunately that would require dynamic regex patterns for a context, which would have a drastic impact on performance.

**valerij_** · November 6, 2017, 7:50pm

so colorocoder is core now. well we had a good run. just sad i didnt get a shoutout

**rppn** · November 6, 2017, 10:59pm

I’ve posted some new *.sublime-color-scheme files to:

https://github.com/jrappen/sublime-color-schemes

which should be available in the package SublimeColorSchemes as soon as my PR on the Package Control channel is merged.

**facelessuser** · November 6, 2017, 11:26pm

Also, if you need to convert one of your favorite schemes (or all of them), you can use this gist:

gist.github.com

https://gist.github.com/facelessuser/20bc65de44b3f6e177fa78f3137e2dee

convert_sublime_color_scheme.py

"""
Convert Color Scheme.

Licensed under MIT.

Copyright (C) 2017  Isaac Muse <isaacmuse@gmail.com>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and

This file has been truncated. show original

It has two commands. One that converts the scheme in your current view, or the other that scans packages (excluding User) and converts them all.

It dumps them all into User/sublime_color_scheme_format. If two packages have schemes with the same name, it will overwrite the last written one in the folder, but you are free to modify the script to create subfolders or even unique names if required.

**ngppgn** · November 7, 2017, 1:26pm

Currently, we can only embed a single pattern at a time. Do you plan to expand it so we can embed a lists of contexts, like we can currently push a list of contexts? That would really help when we have to deal with both nesting and sequential contexts. e.g. an elsif or else context that is only legal immetialy after and at the same level of indentation as th previous if context could be dealth with by `embed: [ else, elif, if]. Probably would need some extra syntax if the escapes and escapes captures are going to be different for the different embedded contexts in the list though.

**FichteFoll** · November 7, 2017, 1:41pm

That seems like a weird usage of embed. Sounds like a case for pushing an anonymous context that includes else, elif and if respectively, imo.

The reason why embed is not correct here is that you need an escape pattern to exit the embed, which may or may not be endif in this case. However, if endif occurs within a comment or a string in that block, the embed will still be exited because escape doesn’t have a concept of context nesting. The escape pattern is matched first, then the text inbetween is passed to the embed context.

Also, it doesn’t make sense to embed multiple contexts at once. If you want to allow multiple "embed"s at the same time, it should be possible to embed an anonymous context and include the two other contexts there instead. I’m not actually sure whether you can embed anonymous contexts though.

**jahan** · November 8, 2017, 4:38pm

all recent build seems to revolve around the aesthetics & rendering of the editor more than any other areas. is there any other new features in the pipeline? i certainly would like have native debugging interface in the core editor. i know same can be achieved by splitting panes etc, but certainly would love to have standard ui build inside the editor. else would love to have enhanced side bar/console api, so plugins can be developed to build ide like debugging interface. i know its still a text editor, having an ui for this certainly helps people like who rely on it. actual debugging functionalities can be provided through LSP and certainly wont “bloat” the editor having an optional debugging interface built in…

**zizzo** · November 8, 2017, 11:03pm

For those that got here searching around a no such target CSS.sublime-syntax#rule-list-body error - check to make sure you don’t have the ‘CSS’ package disabled

**willrowe** · November 9, 2017, 4:02pm

I’m having some issues with a syntax that I have created for a template language.

The template language can be used to generate any type of file and I specifically have a syntax for use with HTML.
Using the with_prototype I was able to inject the template syntax into the existing HTML syntax and everything worked fine until this build.
The issue specifically happens when a template tag is used in the style attribute, other attributes work fine.

Example:
<div class="{{ "this-works-fine" }}" style="background-image: url({{ "this-does-not.jpg" }});"></div>

The only thing I can figure is that it might be an issue with the use of the embed action for style attributes in the HTML syntax. The embed is looking for another double quote, so when it encounters the double quote in the template tag, it immediately pops out of the template contexts as well the style attribute contexts before the actual end of the style attribute. This leaves a seemingly malformed syntax, demonstrated by the highlighting.

Seeing as this worked in build 3152, I’m not quite sure what to make of the issue I’m having. Is this a bug, am I not implementing my syntax correctly, or is it expected behavior?

**wbond** · November 9, 2017, 4:07pm

That is an interesting edge case. I’ll spend a little time thinking about how to handle this.

**kingkeith** · November 14, 2017, 6:51am

there seems to be a major regression in this build which has carried across to 3154:

**qbasic** · November 14, 2017, 8:21am

Build 3153, Windows 7 x64.

After update to this build I’ve got an error:

And I have no markdown syntax anymore.

**qbasic** · November 14, 2017, 8:36am

Another glitch: when I open the Command Palette (Ctrl+Shift+P), I can see it as an inline search control (some input edit and a results list). In this build (3153) its behavior was changed.

Previously: when I open command palette, I can type some text (say, fav to select Favorite files commands), then press Esc to close palette and then open the palette again. Previous text was still available and selected, Up and Down keyboard keys would have allowed to navigate commands up and down.

Currently: when I reopen the command palette, previous text is highlighted still, but Up and Down keys are just moving text cursor left and right which is completely unexpected and inconvenient.

**qbasic** · November 14, 2017, 8:38am

Uh, sorry, all of that was for 3154 (I was confused by backup version value).

**jfcherng** · November 14, 2017, 9:32am

Either use a 3rd-party markdown syntax or disable your 3rd-party CSS syntax(or file an issue to ask them to fix it). ST’s built-in syntax (Markdown) uses built-in scopes which 3rd-party syntax (CSS3, I guess) may not have.

**wbond** · November 14, 2017, 2:20pm

This is almost certainly related to disabling the CSS syntax because you have the CSS3 syntax installed. The author of the CSS3 syntax recently cut a new release to fix this bug, so you may need to upgrade that package.

**adambrenecki** · January 15, 2018, 5:32am

I’ve been experimenting with the “Hashed Syntax Highlighting” feature, and it’s really cool—in fact, I stumbled across this thread and as soon as I saw it, went and bought a ST license and started playing with syntax themes just so I could use that feature.

I do have one question though: is there any chance that "background" will get support for hashed syntax highlighting as well as just "foreground"? What I’m finding with HSH so far is that it’s hard to make the colours bright enough that the feature is useful while still not being overwhelming, not drawing too much attention away from other parts of the file, and keeping enough contrast to make things readable.

Because the background has a larger “surface area”, so to speak, than the foreground, I’m thinking it might present an opportunity to make the colour muted enough that it doesn’t grab attention and/or keep the text dark enough that there’s enough contrast to be readable, while still being noticeable enough that the feature is put to good use.