Are there any standards for tmlanguage keyword types?

Question

.tmlanguage files work by defining a list of key value pairs. Regular expressions are keys, and the syntax type is the value. This is done in the following XML order:

 <key>match</key> <string>[0-9]</string> <key>name</key> <string>constant.numeric</string> 

My main question is: is there a list of values ​​that can be instead of constant.numeric if the file should be used by a text editor such as Sublime?

Answer 1

For a basic introduction, check out Language Grammars in the TextMate Guide. The Naming Conventions section describes some basic areas, such as comment , keyword , meta , storage , etc. These classes can then be subclassed to give as much detail as possible - for example, constant.numeric.integer.long.hexadecimal.python . However, it is very important to note that these are not strict rules - just suggestions. This will become apparent when you scan various language definitions and see, for example, all the different ways in which functions are limited - meta.function-call , support.function.name , meta.function-call punctuation.definition.parameters , etc. .

The best way to learn about the clouds is to examine existing .tmLanguage files and view the source of different languages ​​and see which areas are assigned where. The XML format is very difficult to view, so I use the excellent PackageDev plugin to translate XML into YAML. Then it’s much easier to scan and see which areas are described using regular expressions:

Another way to learn how to use different language constructs, and for this I highly recommend using ScopeAlways . After installation and activation, simply place the cursor, and the areas (areas) that apply to this particular position are displayed in the status bar. This is especially useful when developing color schemes, as you can easily see which selectors will highlight the feature you are interested in.

If you're interested, the Neon color scheme used here, which I developed to make as many languages ​​as possible, covering as many areas as possible. Feel free to browse it to see how the various elements of the language stand out; it can also help you design your .tmLanguage to fit other languages.

Hope all this helps, good luck!

Answer 2

Yes. The .tmlanguage format .tmlanguage originally used by TextMate. The TextMate Guide provides comprehensive documentation for the format, including possible types of language constructs.

Copied from the page of the relevant documents in a hierarchical format:

• comment - for comments.
  • line - , we additionally specialize in that the type of character (s) for starting comments can be extracted from the field
    • double-slash - // comment
    • double-dash - -- comment
    • number-sign - # comments
    • percentage - % comment
    • character - other types of line comments.
  • block - multi-line comments, such as /* … */ and <!-- … --> .
    • documentation - built-in documentation.
• constant - various forms of constants.
  • numeric - those that represent numbers, for example. 42 , 1.3f , 0x4AB1U .
  • character - those that represent characters, for example. < , \e , \031 .
  • escape - escape sequences such as \e will be constant.character.escape .
  • language - constants (usually) provided by the language, which are "special", such as true , false , nil , YES , NO , etc.
  • other - other constants, for example. colors in CSS.
• entity - An object refers to most of a document, such as a chapter, class, function, or tag. We do not cover the entire object as entity.* (For this we use meta.* ). But we use entity.* For “placeholders” in a larger object, for example. if the object is a chapter, we will use entity.name.section for the title of the chapter.
  • name - we call a larger object.
    • function is the name of the function.
    • type - the name of the declaration of the type or class.
    • tag is the name of the tag.
    • section - name is the name of the section / title.
  • other - other objects.
    • inherited-class is the name of the superclass / base word.
    • attribute-name - attribute name (mainly in tags). we call a larger entity.
• invalid - which is invalid.
  • illegal - illegal, for example. ampersand or lower character in HTML (which is not part of the entity / tag).
  • deprecated - for obsolete things, for example. using an API function that is deprecated or uses style with strict HTML.
• keyword - (if they do not fall into other groups).
  • control - mainly related to flow control, e.g. continue, while, return, etc.
  • operator - can be text (for example, or) or be characters.
  • other - other keywords.
• markup is for markup languages ​​and is usually applied to larger subsets of text.
  • underline - underlined text.
    • link is for links, because this convenience comes from markup.underline , so if there is no theme rule that is specifically designed for markup.underline.link , then it inherits the underline style.
  • bold - bold text ( strong and similar text should be obtained from this name).
  • heading - section heading. Optionally, specify the header level as the next element, for example markup.heading.2.html for <h2>…</h2> in HTML.
  • italic is italic text (text that is em phased and similar should preferably be derived from this name).
  • list - .
    • numbered - numbered list items.
    • unnumbered - unnumbered list items.
  • quote - quoted (sometimes frame-locked) text.
  • raw is text that is verbatim, for example. lists of codes. Typically, spell checking is disabled for markup.raw .
  • other - other markup constructs.
• meta - A meta object is commonly used to mark up large parts of a document. For example, the entire line declaring a function will be meta.function , and the subsets will be storage.type , entity.name.function , variable.parameter , etc., And only the last one will be styled. Sometimes the meta part of an area will be used only to limit the more general element that is used in the style, however, most of the temporary metadata is used in area selectors to activate the elements of the package. For example, in Objective-C, there is a meta area for declaring a class interface and implementation, allowing the same trigger tabs to expand differently, depending on the context.
• storage - things related to "storage".
  • type - the type of something, class , function , int , var , etc.
  • modifier - storage modifier, e.g. static , final , abstract , etc.
• string - .
  • quoted quoted lines.
    • single - single quotes: 'foo' .
    • double - double quotes: "foo" .
    • triple - triple quoted strings: """Python""" .
    • other - other types of citation: $'shell' , %s{...} .
  • unquoted - for things like here-docs and here-strings.
  • interpolated - strings that are "evaluated": `date` , $(pwd) .
  • regexp - regular expressions: /(\w+)/ .
  • other - other types of strings (rarely used).
• support - things provided by the framework or library should be below support.
  • function - provided by the framework / library. For example, Objective-C's NSLog has support.function .
  • class - when the environment / library provides classes.
  • type - provided by the infrastructure / library, probably this is only used for languages ​​derived from C, which has typedef (and struct ). Most other languages ​​will introduce new types as classes.
  • constant - constants (magic values) provided by the framework / library.
  • variable - provided by the infrastructure / library. For example, NSApp in AppKit.
  • other - the above should be comprehensive, but for everything else, use support.other .
• variable - . Not all languages ​​make it easy to identify (and therefore markup) these.
  • parameter - when a variable is declared as a parameter.
  • language - reserved language variables such as this , super , self , etc.
  • other - other variables, for example $some_variables .