diff --git a/www.sublimetext.com/docs/3/color_schemes.html b/www.sublimetext.com/docs/3/color_schemes.html index 9ce41fc..5e7690f 100644 --- a/www.sublimetext.com/docs/3/color_schemes.html +++ b/www.sublimetext.com/docs/3/color_schemes.html @@ -340,6 +340,10 @@
block_caret
setting is enabled. Defaults to the selection background color if not specified.
+ + The diff functionality is displayed in the gutter as colored lines + for added and modified lines, and a triangle where lines were + deleted. +
+block_caret
setting
+ line_diff_added
and
+ line_diff_deleted
settings
+ line_diff_modified
and
+ line_diff_width
settings
+ saturation()
and lightness()
adjusters
+ Added the saturation()
and
+ lightness()
adjusters
foreground_adjust
key for style rules
+ Added the foreground_adjust
key for style
+ rules
This is a living document that attempts to document best practices for using scope names in syntax definitions and color schemes. All of the Sublime Text default packages strive to adhere to these recommendations.
+ +keyword.control.ruby
, whereas in Python it would be keyword.control.python
.
+ - It is an on-going process to improve and expand upon the default syntaxes that are shipped with Sublime Text. As of mid-2016, the following syntaxes have been recently re-worked, and may be used as a reference: + It is an on-going process to improve and expand upon the default syntaxes that are shipped with Sublime Text. As of early-2019, the following syntaxes have been recently re-worked, and may be used as a reference:
-The following, top-level, list of scopes is sorted alphabetically. It is recommended to read through the entire list at least once before writing or modifying a syntax. @@ -171,7 +189,7 @@
comment.
comment.
@@ -218,7 +236,7 @@
comment.
constant.
constant.
@@ -231,17 +249,52 @@
constant.
constant.numeric.integer
constant.numeric.integer.binary
+ constant.numeric.integer.octal
+ constant.numeric.integer.decimal
+ constant.numeric.integer.hexadecimal
+ constant.numeric.integer.other
+ constant.numeric.float
constant.numeric.hex
+ constant.numeric.float.binary
+ constant.numeric.float.octal
+ constant.numeric.float.decimal
+ constant.numeric.float.hexadecimal
+ constant.numeric.float.other
+ constant.numeric.complex
+ constant.numeric.complex.real
constant.numeric.octal
+ constant.numeric.complex.imaginary
Constants that are built into the language, such as booleans and null values, should use:
@@ -250,9 +303,7 @@constant.
constant.language
-
Character escapes in strings, e.g. \n
and \x20
, should use:
constant.
entity.
entity.
The entity scopes are generally assigned to the names of data structures, types and other uniquely-identifiable constructs in code and markup. The notable exceptions are entity.name.tag
and entity.other.attribute-name
, which are used in HTML and XML tags.
@@ -315,6 +366,9 @@
entity.
entity.name.interface
entity.name.impl
+ entity.name.type
entity.
invalid.
invalid.
@@ -439,7 +493,7 @@
invalid.
keyword.
keyword.
@@ -510,7 +564,7 @@
keyword.
markup.
markup.
Markup scopes are used for content, as opposed to code. This includes syntaxes such as Markdown and Textile. @@ -609,7 +663,7 @@
markup.
meta.
meta.
Meta scopes are used to scope larger sections of code or markup, generally containing multiple, more specific scopes. These are not intended to be styled by a color scheme, but used by preferences and plugins. @@ -638,6 +692,9 @@
meta.
meta.interface
meta.impl
+ meta.type
meta.
+ Annotations, attributes and decorator statements that are used to modify the behavior or implementation of a class, method or function should use one of the following meta
scopes for each component of the annotation. That is to say, there should never be more than one meta.annotation*
scope on the stack at any given time. See variable.annotation
for scoping the identifier.
+
meta.annotation
+ meta.annotation.identifier
+ meta.annotation.parameters
+ punctuation.definition.annotation
+
Complete identifiers, including namespace names, should use the following scope. Such identifiers are the fully-qualified forms of variable, function and class names. For example, in C++ a path may look like myns::myclass
, whereas in PHP it would appears such as \MyNS\MyClass
.
meta.
meta.path
+
Function names, including the full path, and all parameters should receive the following scope. The name of the function or method should be variable.function
, unless the function is scoped with support.function
.
meta.
meta.function-call
-
Sections of code delineated by curly braces should use one the following meta
scopes, based on appropriate semantics. The {
and }
characters should additionally use the punctuation
scopes.
meta.
punctuation.
punctuation.
The following scopes are punctuation scopes that are not embedded within other scopes. For instance, the string.
section includes documentation about scopes for string punctuation.
@@ -843,7 +918,7 @@
punctuation.
source.
source.
@@ -858,20 +933,18 @@
source.
storage.
storage.
- Types and definition/declaration keywords should use the following scope. Examples include int
, bool
, char
, func
, function
, class
and def
. Depending on the language and semantics, const
may be this or storage.modifier
.
+ Types should use the following scope. Examples include int
, bool
and char
.
storage.type
Keywords that affect the storage of a variable, function or data structure should use the following scope. Examples include static
, inline
, const
, public
and private
.
storage.
storage.modifier
+
+
+ Keywords for functions or methods should use the following scopes. Example keywords include func
, function
and def
. This includes storage.type
for backwards compatibility with older color schemes.
+
storage.type.function keyword.declaration.function
+
+ Keywords for classes, structs, interfaces, etc should use the following scopes – this list is not exhaustive. Example keywords include class
, struct
, impl
and typedef
. This includes storage.type
for backwards compatibility with older color schemes.
+
storage.type.class keyword.declaration.class
+ storage.type.struct keyword.declaration.struct
+ storage.type.enum keyword.declaration.enum
+ storage.type.union keyword.declaration.union
+ storage.type.trait keyword.declaration.trait
+ storage.type.interface keyword.declaration.interface
+ storage.type.impl keyword.declaration.impl
+ storage.type keyword.declaration.type
+ string.
string.
@@ -910,9 +1026,16 @@
string.
string.quoted.other
- + The entirety of a string, along with all punctuation, prefixes, suffixes and interpolations should use: +
+meta.string
+ Punctuation at the beginning and end of strings should use:
@@ -943,10 +1066,42 @@string.
+ When a string contain interpolated code, such as a variable or expression, the string.*
scope should be removed using clear_scopes:
, and the following should be added to the entirety of the interpolation, including punctuation:
+
meta.interpolation
+ + The punctuation for an interpolated expression should be: +
+punctuation.section.interpolation.begin
+ punctuation.section.interpolation.end
+ + Between the punctuation, the interpolated expression should get: +
+source.language-suffix.embedded
+ support.
support.
@@ -981,7 +1136,7 @@
support.
text.
text.
Programming languages use source.
as their base scope, whereas content uses text.
. One of the biggest differences is the fact that many plugins and other dynamic functionality is disabled within text.
scopes. markup.
scopes are typically used within text.
@@ -1011,7 +1166,7 @@
text.
variable.
variable.
@@ -1052,9 +1207,7 @@
variable.
variable.language
- Parameters to a function or methods should use the following scope. This may also be used for other parameter-like variables, such as receivers or named return values in Go.
@@ -1063,7 +1216,9 @@variable.
variable.parameter
+ Fields, properties, members and attributes of a class or other data structure should use:
@@ -1081,6 +1236,25 @@variable.
variable.function
+
+
+ The final label in an identifier that is part of an annotation should use the following. For the entire identifier, the meta.path
scope should be used. The entire annotation should get meta.annotation
.
+
variable.annotation
+ + The leading symbol used to delineate an annotation should use: +
+ +punctuation.definition.annotation
+ keyword
keyword.control
keyword.operator
keyword.declaration
string
comment
invalid
+ Certain labels allow for additional control over their appearance. + They support the properties: +
+ ++ The container holding information about a file or folder + in the sidebar. Contains different controls based on which + section of the sidebar it is within. +
+
+ Within the Open Files section, this control
+ will contain a sidebar_label
with the file
+ name, plus possibly a vcs_status_badge
.
+
+ Within the Folders section, this control
+ will contain a folder or file icon (either
+ icon_folder
, icon_folder_loading
,
+ icon_folder_dup
or
+ icon_file_type
), a sidebar_label
+ with the file or folder name, plus possibly a
+ vcs_status_badge
.
+
@@ -1255,6 +1351,70 @@
+ An icon contained within file_system_entry
that
+ is used to display the status of a file or folder with
+ regards to a Git repository it is contained in. This icon
+ will only be shown if the setting
+ show_git_status
is true
, the file
+ is contained within a Git repository, and the file has some
+ sort of special state within the repository. A file that
+ is not shown via git status
and is not ignored
+ via a .gitignore rule will
+ have no icon.
+
+ The container holding the vcs_branch_icon
,
+ label_control
with the current branch name,
+ and vcs_changes_annotation
control
+
+ An icon shown to the left of the current branch name +
++ Displays the number of files that have been added, modified + or deleted +
+scroll_area_control
gained the
+ scrollable
and hscrollable
+ attributes
+ file_system_entry
and
+ vcs_status_badge
controls to the sidebar
+ vcs_status
,
+ vcs_branch_icon
and
+ vcs_changes_annotation
controls to the
+ status bar
+ sidebar_heading
element now has the case
property
+ The sidebar_heading
element now has the
+ case
property
scroll_area_control
gained the ability to set shadows on any side that can be scrolled
+ scroll_area_control
gained the ability to
+ set shadows on any side that can be scrolled
- The following pages contain the official documentation for Sublime Text 3. The Sublime Text Unofficial Documentation is an excellent supplementary resource, with a huge amount of information not covered in the official documentation. + The following pages contain the official documentation for Sublime Text 3. The Sublime Text Unofficial Documentation is an excellent supplementary resource, with a huge amount of information not covered in the official documentation.
This is a living document that attempts to document best practices for using scope names in syntax definitions and color schemes. All of the Sublime Text default packages strive to adhere to these recommendations.
+ +keyword.control.ruby
, whereas in Python it would be keyword.control.python
.
+ - It is an on-going process to improve and expand upon the default syntaxes that are shipped with Sublime Text. As of mid-2016, the following syntaxes have been recently re-worked, and may be used as a reference: + It is an on-going process to improve and expand upon the default syntaxes that are shipped with Sublime Text. As of early-2019, the following syntaxes have been recently re-worked, and may be used as a reference:
-The following, top-level, list of scopes is sorted alphabetically. It is recommended to read through the entire list at least once before writing or modifying a syntax. @@ -171,7 +189,7 @@
comment.
comment.
@@ -218,7 +236,7 @@
comment.
constant.
constant.
@@ -231,17 +249,52 @@
constant.
constant.numeric.integer
constant.numeric.integer.binary
+ constant.numeric.integer.octal
+ constant.numeric.integer.decimal
+ constant.numeric.integer.hexadecimal
+ constant.numeric.integer.other
+ constant.numeric.float
constant.numeric.hex
+ constant.numeric.float.binary
+ constant.numeric.float.octal
+ constant.numeric.float.decimal
+ constant.numeric.float.hexadecimal
+ constant.numeric.float.other
+ constant.numeric.complex
+ constant.numeric.complex.real
constant.numeric.octal
+ constant.numeric.complex.imaginary
Constants that are built into the language, such as booleans and null values, should use:
@@ -250,9 +303,7 @@constant.
constant.language
-
Character escapes in strings, e.g. \n
and \x20
, should use:
constant.
entity.
entity.
The entity scopes are generally assigned to the names of data structures, types and other uniquely-identifiable constructs in code and markup. The notable exceptions are entity.name.tag
and entity.other.attribute-name
, which are used in HTML and XML tags.
@@ -315,6 +366,9 @@
entity.
entity.name.interface
entity.name.impl
+ entity.name.type
entity.
invalid.
invalid.
@@ -439,7 +493,7 @@
invalid.
keyword.
keyword.
@@ -510,7 +564,7 @@
keyword.
markup.
markup.
Markup scopes are used for content, as opposed to code. This includes syntaxes such as Markdown and Textile. @@ -609,7 +663,7 @@
markup.
meta.
meta.
Meta scopes are used to scope larger sections of code or markup, generally containing multiple, more specific scopes. These are not intended to be styled by a color scheme, but used by preferences and plugins. @@ -638,6 +692,9 @@
meta.
meta.interface
meta.impl
+ meta.type
meta.
+ Annotations, attributes and decorator statements that are used to modify the behavior or implementation of a class, method or function should use one of the following meta
scopes for each component of the annotation. That is to say, there should never be more than one meta.annotation*
scope on the stack at any given time. See variable.annotation
for scoping the identifier.
+
meta.annotation
+ meta.annotation.identifier
+ meta.annotation.parameters
+ punctuation.definition.annotation
+
Complete identifiers, including namespace names, should use the following scope. Such identifiers are the fully-qualified forms of variable, function and class names. For example, in C++ a path may look like myns::myclass
, whereas in PHP it would appears such as \MyNS\MyClass
.
meta.
meta.path
+
Function names, including the full path, and all parameters should receive the following scope. The name of the function or method should be variable.function
, unless the function is scoped with support.function
.
meta.
meta.function-call
-
Sections of code delineated by curly braces should use one the following meta
scopes, based on appropriate semantics. The {
and }
characters should additionally use the punctuation
scopes.
meta.
punctuation.
punctuation.
The following scopes are punctuation scopes that are not embedded within other scopes. For instance, the string.
section includes documentation about scopes for string punctuation.
@@ -843,7 +918,7 @@
punctuation.
source.
source.
@@ -858,20 +933,18 @@
source.
storage.
storage.
- Types and definition/declaration keywords should use the following scope. Examples include int
, bool
, char
, func
, function
, class
and def
. Depending on the language and semantics, const
may be this or storage.modifier
.
+ Types should use the following scope. Examples include int
, bool
and char
.
storage.type
Keywords that affect the storage of a variable, function or data structure should use the following scope. Examples include static
, inline
, const
, public
and private
.
storage.
storage.modifier
+
+
+ Keywords for functions or methods should use the following scopes. Example keywords include func
, function
and def
. This includes storage.type
for backwards compatibility with older color schemes.
+
storage.type.function keyword.declaration.function
+
+ Keywords for classes, structs, interfaces, etc should use the following scopes – this list is not exhaustive. Example keywords include class
, struct
, impl
and typedef
. This includes storage.type
for backwards compatibility with older color schemes.
+
storage.type.class keyword.declaration.class
+ storage.type.struct keyword.declaration.struct
+ storage.type.enum keyword.declaration.enum
+ storage.type.union keyword.declaration.union
+ storage.type.trait keyword.declaration.trait
+ storage.type.interface keyword.declaration.interface
+ storage.type.impl keyword.declaration.impl
+ storage.type keyword.declaration.type
+ string.
string.
@@ -910,9 +1026,16 @@
string.
string.quoted.other
- + The entirety of a string, along with all punctuation, prefixes, suffixes and interpolations should use: +
+meta.string
+ Punctuation at the beginning and end of strings should use:
@@ -943,10 +1066,42 @@string.
+ When a string contain interpolated code, such as a variable or expression, the string.*
scope should be removed using clear_scopes:
, and the following should be added to the entirety of the interpolation, including punctuation:
+
meta.interpolation
+ + The punctuation for an interpolated expression should be: +
+punctuation.section.interpolation.begin
+ punctuation.section.interpolation.end
+ + Between the punctuation, the interpolated expression should get: +
+source.language-suffix.embedded
+ support.
support.
@@ -981,7 +1136,7 @@
support.
text.
text.
Programming languages use source.
as their base scope, whereas content uses text.
. One of the biggest differences is the fact that many plugins and other dynamic functionality is disabled within text.
scopes. markup.
scopes are typically used within text.
@@ -1011,7 +1166,7 @@
text.
variable.
variable.
@@ -1052,9 +1207,7 @@
variable.
variable.language
- Parameters to a function or methods should use the following scope. This may also be used for other parameter-like variables, such as receivers or named return values in Go.
@@ -1063,7 +1216,9 @@variable.
variable.parameter
+ Fields, properties, members and attributes of a class or other data structure should use:
@@ -1081,6 +1236,25 @@variable.
variable.function
+
+
+ The final label in an identifier that is part of an annotation should use the following. For the entire identifier, the meta.path
scope should be used. The entire annotation should get meta.annotation
.
+
variable.annotation
+ + The leading symbol used to delineate an annotation should use: +
+ +punctuation.definition.annotation
+ keyword
keyword.control
keyword.operator
keyword.declaration
string
comment
invalid