SublimeText. Highlighting similar keywords - in different colors - sublimetext3

How can i do this in SublimeText (see the image below)?
Is it possible do by using .sublime-syntax (%YAML1.2) or maybe another way?
Will be wonderful if anyone can provide me with some example. Thanks.

Ok, nobody knows. This small example how it may works.
%YAML 1.2
---
name: MyCustomSyntax
file_extensions: txt
scope: source.txt
contexts:
main:
- comment: "mykey operator definition"
match: mykey(?= *?= *?\{)
scope: keyword.txt
- comment: "mykey structure definition"
match: mykey(?! *?= *?\{)
scope: string.txt
- comment: "other operator definition"
match: (=|{|})
scope: comment.txt

Related

How to embed inline C++ syntax in another language definition?

I have a custom Perl syntax file for Sublime Text 3 and I would like to add an highlighting support for embedded C++ code.
The inline C++ code always starts with __CPP__ and ends with __END__ among the perl code.
I'm using the 'embed/match/escape' approach but the syntax highliting of the C++ code won't change (getting the scope with ctrl-alt-shift-p it still appears as source.perl).
Here the rule I'm using in my syntax file:
contexts:
main:
- include: inline-cpp
...lot of rules...
inline-cpp:
- match: '__CPP__'
embed: scope:source.c++
embed_scope: source.c++.embedded
escape: '__XXX__'
Please could someone help me figure out what I'm doing wrong?
Solved putting the include in prototype section instead of main :
contexts:
main:
...
prototype:
- include: inline-cpp
inline-cpp:
- match: '__CPP__'
embed: scope:source.c++
embed_scope: source.c++.embedded
escape: '__XXX__'

Prevent yargs describe feature from showing auto-generated tags

When using yargs .describe method to generate usage information, is there some way to prevent yargs from auto-adding information about type, default value, choices etc.?
I.e. the following
.option('foo', {
type: 'string',
choices: ['bar','baz'],
required: true,
default: 'bar',
description: 'The most important option of all'
})
results in this output when doing --help:
--foo The most important option of all [string] [required] [choices: "bar", "baz"] [default: "bar"]
I find that to be ugly, out of line with how help texts are generally formatted in linux, and confusing to read. Also, on longer description texts that include line breaks, it breaks formatting.
I haven't found anything in the docs. Anyone know of a way to do this, without having to completely give up yargs' describe feature?

How to correctly embed another language into my current language defintion?

I have Smalltalk sublime-syntax file (YAML) for Sublime Text 3 and I would like to add an highlighting support for embedded C code.
The inline C (which always starts with ^%\{ and ends with %\}$) code among the smalltalk code.
A simple example (not much C but wanted a simple case):
sigABRT
"return the signal number for SIGABRT - 0 if not supported by OS
(the numeric value is not the same across unix-systems)"
%{ /* NOCONTEXT */
#ifdef SIGABRT
RETURN ( __mkSmallInteger(SIGABRT) );
#else
RETURN ( __mkSmallInteger(0) );
#endif
%}
!
There is new feature embed in Sublime text (with even an example).
I tried to do something like this:
- match: '^%\{'
embed: scope:source.c
embed_scope: meta.environment.embedded.c.smalltalk source.c.embedded
escape: '%\}$'
However, I was unable to correctly incorporate it into my current highlighting file.
Does anyone know how to correctly embed one language to another?
This question is a little sticky because you've provided a sample syntax definition and a sample of some Smalltalk source code, but the code provided is not highlighted by the provided syntax because it's not structured properly.
For our purposes here, lets assume that the Smalltalk sample you provided is the following one. This may or may not be valid (it's been a long time since I've worked with Smalltalk) but it highlights with your syntax, so lets call that good enough for testing purposes.
Object subclass: Test [
sigABRT
"return the signal number for SIGABRT - 0 if not supported by OS
(the numeric value is not the same across unix-systems)"
%{ /* NOCONTEXT */
#ifdef SIGABRT
RETURN ( __mkSmallInteger(SIGABRT) );
#else
RETURN ( __mkSmallInteger(0) );
#endif
%}
!
].
The syntax match that you provided above is the correct one to use, so I'm guessing that your problem is in where you placed it in the syntax.
So lets presume that there is more than one place where we might want to match one of these C blocks in the syntax definition; in that case we may want to create a new context in the syntax that contains the match so that we can include it where it's needed:
c-block:
- match: '%\{'
embed: scope:source.c
embed_scope: meta.environment.embedded.c.smalltalk source.c.embedded
escape: '%\}$'
This is the same excerpt as you provided above, but placed into a context. So lets say that the first place where a block such as this can appear is in the body of a block. You have a block-body context in your syntax, so we stick an include onto the end of it to include this new context:
block-body:
- include: pragma
- include: selector
- include: literal
- include: block
- include: comment
- include: c-block
However, this does not have the desired outcome; the highlight is not correct:
Clearly the highlighting is going wrong starting at least at the C comment start, possibly earlier. If you use Tools > Developer > Show Scope Name while the cursor is on the comment, you can see that the scope assigned is source.smalltalk entity.name.function, which means that the syntax is treating the C comment start as a method name.
It also looks like the %{ construct is not properly highlighted, and a check shows that the scope of the % character is source.smalltalk keyword.other.
So in reality the problem currently is that with the above definitions in place, instead of seeing %{ as starting a C block, it's being seen as a keyword, and if it's a keyword then the rules for matching a C block are not triggering at all.
If you look at your syntax, the main context looks like this:
main:
- match: '([a-zA-Z][a-zA-Z0-9]*)\s*(subclass:)\s*([a-zA-Z][a-zA-Z0-9]*)\s*\['
captures:
1: entity.other.inherited-class
2: keyword.other
3: entity.name.type
push:
- match: '\]'
pop: true
- include: pragma
- match: '(([a-zA-Z][a-zA-Z0-9]*:)|[+\-\/\\*~<>=#%|&?!.,:;^]+)\s*([a-zA-Z][a-zA-Z0-9]*)'
captures:
1: entity.name.function
3: variable.other
- match: "([a-zA-Z][a-zA-Z0-9]*)"
scope: entity.name.function
- include: block
- include: comment
- include: block-body
These rules say that when we see a line that starts with something like BaseClass subclass: SubClass [, we are entering into an anonymous context (via the push) to handle the contents of the class body (or block or whatever).
The anonymous context contains the rule to pop out when it sees the closing ] character, two different matches to find a function name, then an include on the contexts for block, comment and block-body respectively.
When you include, Sublime takes all of the match rules from that context and inserts a copy of them at the point where you do the insert, as if you had just manually entered them there.
In addition, when there is more than one rule in a context that might potentially match, the first match rule in the context is the one that is applied (i.e. it "wins" the tie).
The scope keyword.other is applied in the rules from the pragma context as well as the selector context, and the selector context can match single % character as a keyword.
Thus the problem here is that since the include c-block appears after selector in the include list for the block-body context, the selector context is finding and matching the % character before the rule for the C block can find it.
The solution then would be to shift the location of the include c-block to be prior to that item to make sure that it matches first:
block-body:
- include: c-block
- include: pragma
- include: selector
- include: literal
- include: block
- include: comment
With that in place, the block highlights more like we would expect:
I was able to work around a similar issue with Regex lookahead and lookbehinds
- match: ' (?=\{")'
embed: scope:source.json
escape: '(?<=\})$'

Modify a line in a scope with Ansible

I need to modify a line in a file. Only problem, the line appears multiple times, but in different scopes. Like in this example from wso2 configuration manual :
<KeyStore>
<Location>${carbon.home}/resources/security/wso2carbon.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyAlias>wso2carbon</KeyAlias>
<KeyPassword>wso2carbon</KeyPassword>
</KeyStore>
<TrustStore>
<!-- trust-store file location -->
<Location>${carbon.home}/repository/resources/security/client-truststore.jks</Location>
<!-- trust-store type (JKS/PKCS12 etc.) -->
<Type>JKS</Type>
<!-- trust-store password -->
<Password>wso2carbon</Password>
</TrustStore>
I would need for example to modify the <Password> entry with one value in the <Keystore> scope, and with a second different value in the <TrustStore> scope in order to have different passwords. Can the lineinfile module do that ? Or is there any other way ?
PS.
Using a template is not the solution I am looking for, as I would like to use this to modify preexisting servers and not lose any local modification.
You can't do this with lineinfile, because it handles every line of the file separately – so there's no context from other lines possible.
Regex in lineinfile is not multiline.
You can use replace – it uses multiline regex.
For example:
- replace:
backup: yes
dest: config.xml
regexp: '(<{{ item.scope }}>[\S\s]*<Password>)(?!{{ item.password }}<).*(</Password>[\S\s]*</{{ item.scope }}>)'
replace: '\1{{ item.password }}\2'
with_items:
- scope: KeyStore
password: foo
- scope: TrustStore
password: bar
Keep in mind that this solution is not bulletproof – scope names and password shouldn't have any XML special characters or regular expression sequences. Also I can't say for sure how it handles nested XML blocks with the same scope name.
But for general cases it should be fine.
There's even a try to be idempotent – it will not match a block if the password is the same.
Ansible lineinfile regex parameter can match multiple lines. There is no problem in that beside that the regex would be long and hard to understand and maintain.
As you are trying to manipulate XML ansible-xml module might be a good option to solve this problem.

How can I change text colour in sublime text?

I want to color source code as i want. For example, if I have this code
<script>
var x = 1;
function yu() {
document.getElementById("e").innerHTML = "O";
}
</script>
I want to color the whole function ( lines 3,4,5), or color just a line or a word. I don't want sublime text to color every word depending of the type of the words.
If it cant be done in sublime text, do you know other source code editros or IDE which an do that?
You can write a custom syntax which meets your criteria and set it as the default syntax for any filetypes you wish to affect.
Here is a basic syntax example which affects files with the extension .MyExtension
Save the following code #:
Packages/MySyntaxFiles/MyCustomSyntax.sublime-syntax
%YAML 1.2
---
name: MyCustomSyntax
file_extensions: [ MyExtension ]
scope: source.MyScopeName
contexts:
main:
- match: '\bfunction.*?{'
push: function
- match: '\b<.+?>\b'
scope: entity.name.tag
function:
- meta_scope: entity.name.function
- include: braces
braces:
- match: '{'
push: braces
- match: '}'
pop: true
Note: This example meets the minimal requirements of the code sample you provided. You will likely need to elaborate upon this template in order for it to fully meet your actual usage requirements.
Resources:
SublimeText > Official Documentation > Syntax
SublimeText > Unofficial Documentation > Syntax Definitions
ScopeHunter
Use this to find scopes that you might want to replicate
PackageResourceViewer
Use this to open existing sublime-syntax files for reference
Color Schemes
Browse the included tmTheme files to view commonly used scopes.
For maximum customization: create your own tmTheme file to match your syntax & scopes.
RegExr
You will need a basic knowledge of RegEx in order to define scope matches.
RegExr has an excellent Reference section which covers most of the basics, along with a testing area so you can try things out as you learn.

Resources