I am trying to create my own syntax highlighting for Sublime Text 3. The main purpose of it is to distinguish text written in Latin script from text written in Cyrillic script. I have already installed AAAPackageControl and read the tutorial, but I cannot make it work for some reason.
Here's the syntax I wrote
# [PackageDev] target_format: plist, ext: tmLanguage
---
name: ADVANCED TEXT
scopeName: text.mirkowy
fileTypes: []
uuid: 78dbe755-58eb-4cdf-b954-4438334aedb9
patterns:
- comment: Words in Latin Script
name: latin_text.text.mirkowy
match: [A-Za-z]+
- comment: Words in Cyrillic Script
name: cyrillic_text.text.mirkowy
match: [ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюяёђѓєѕіїјљњћќўџҐґ]+
- comment: Numbers
name: numbers.text.mirkowy
match: \d
...
However, when I press F7 to convert that file to plist, I keep getting and error and I don't understand why (bear in mind that I am completely new to creating one's own syntaxes and the like) — here's what it looks like:
Input type not specified, auto-detecting... YAML
No target format specified, searching in file... Property List
Parsing YAML... (C:\Users\iyoossaev\AppData\Roaming\Sublime Text 3\Packages\User\mirkowy.YAML-tmLanguage)
Error parsing YAML: while parsing a block mapping
What do I do wrong?
You almost got it, but there is a minor issue with your regexes - character classes surrounded by square brackets [ ] need to be within parentheses ( ). Your "Numbers" regex \d works fine without parens. So, just change your code to the following:
# [PackageDev] target_format: plist, ext: tmLanguage
---
name: ADVANCED TEXT
scopeName: text.mirkowy
fileTypes: []
uuid: 78dbe755-58eb-4cdf-b954-4438334aedb9
patterns:
- comment: Words in Latin Script
name: latin_text.text.mirkowy
match: ([A-Za-z]+)
- comment: Words in Cyrillic Script
name: cyrillic_text.text.mirkowy
match: ([ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюяёђѓєѕіїјљњћќўџҐґ]+)
- comment: Numbers
name: numbers.text.mirkowy
match: \d
and you should be all set. Note that I put a blank space between each block - it's not required, but it helps you visually separate each block, which comes in very useful when you get very complicated blocks.
If you'd like some examples of more complex .YAML-tmLanguage syntax definitions, two places come immediately to mind. The first is the Syntax Definitions folder in the PackageDev package itself. The second is actually in a personal project of mine, the Python Improved syntax definition which aims to be a much better replacement for the built-in Python syntax that ships with Sublime. You can find the source for PythonImproved.YAML-tmLanguage on Github. Feel free to open an issue there if you have any questions on syntax design, or just ask a new question here.
Good luck!
Related
Very difficult to understand ansible behavior. I'm trying to edit my /etc/postfix/master.cf file to turn on the submission block.
I copied the file to /tmp as I'm working on it, so my simple Ansible playbook should be:
- name: Edit the master.cf file
replace:
path: /tmp/master.cf
after: '^#tlsproxy'
before: '^#smtps'
regexp: '^#(.*)$'
replace: '\1'
But this doesn't work. It does work if I make one change, which is taking out the caret ^ in the before and after fields. This makes ... no sense to me at all. What makes even less sense, if I use:
after: '^#'
amazingly, it will do what I expect and uncomment all the lines after the first commented line.
But:
after: '^#t'
suddenly stops matching anything. I've read the Python page on regex and yet I'm baffled by this.
Any ideas? The playbook will work fine without the carets but I want to do this really correctly and match exactly what I want to match.
Thanks!
Ansible's replace module: uses DOTALL, which means the . special character can match newlines.
When you specify after: '^#tlsproxy', that caret is really saying: 'from the beginning of the search string, immediately followed by #tlsproxy', where the caret effectively means from the beginning of the file.
Ansible tries to match this:
"Pattern for before/after params did not match the given file: ^#tlsproxy(?P<subsection>.*?)^#smtps"
With re.DOTALL, if you want to match the patterns from the beginning of a line, use a newline character instead:
- name: Edit the master.cf file
replace:
path: master.cf
after: '\n#tlsproxy'
before: '\n#smtps'
regexp: '^#(.*)$'
replace: '\1'
I'm running an ansible playbook that allows me to (or should allow me to) replace two lines in a configuration file for a remote server. Most of the file replacements are dictionary style entries where neither the key nor the value have quotes. But there is one replacement where the name needs to be quoted. Here is the task from the ansible playbook:
- name: Enable traefikExporter within vars.jsonnet configuration file.
ansible.builtin.replace:
path: /home/bill/cluster-monitoring/vars.jsonnet
regexp: "name: 'traefikExporter',[\n\r].*[\n\r]"
replace: |6
name: 'traefikExporter',
enabled: true,
The error thrown is:
The offending line appears to be
replace: |6
name: 'traefikExporter'
^ here
and it notes that it is a mismatched quote. But I've tried changing the yaml replace parameter to > and using \n for line breaks on a single line as well as the | with quoted lines. They all throw versions of the mismatched quote error.
For reference, the following task, which is immediately above this task, runs correctly without errors:
- name: Enable k3s Monitoring within vars.jsonnet configuration file.
ansible.builtin.replace:
path: /home/bill/cluster-monitoring/vars.jsonnet
regexp: "\ k3s: {[^}]*},"
replace: |2
k3s: {
enabled: true,
master_ip: ['192.168.2.139'],
},
The closest thing I could find is here, but this didn't work. In both cases the regexp covers multiple lines and the replace covers the same lines identified by the regexp. What am I missing?
update
I also tried replacing the replacement text and now believe that the actual formatting issue is in the regexp: "name: 'traefikExporter',[\n\r].*[\n\r]" line. No matter what I place in the replace line it throws the error. I think the quotes in the regexp are the issue.
work around
I came up with a work around but it still isn't right. The following is very close to what I'd like - but a bit frustrated that it isn't exactly what I expected:
- name: Enable traefikExporter within vars.jsonnet configuration file.
ansible.builtin.replace:
path: /home/bill/cluster-monitoring/vars.jsonnet
regexp: "name: 'traefikExporter',[\n\r].*"
replace: >4
name: 'traefikExporter',
enabled: true,
The |6 or >6 was the problem - but not sure why. My expected behavior was to have a 6 space indent. But this is the thing throwing the error. When I put it to 4 there is no quote error. But as you can see - to get the formatting right I have to do some weird spacing (the name: is the correct indentation with the 4, but I have to add 6 actual spaces to get the next line to align. Not part of this question - but neither the | nor the > seems to impact the trailing return in both cases there is an extra line after the replacement.
YAML processes escape sequences in double-quoted scalars, so you should use
regexp: "name: 'traefikExporter',[\\n\\r].*[\\n\\r]"
I suggest however to use a block scalar to avoid escaping hell:
regexp: >-
name: 'traefikExporter',[\n\r].*[\n\r]
Regarding the indentation indicator, this cannot work:
replace: |6
name: 'traefikExporter',
enabled: true,
You are basically saying „the following block scalar has 6 spaces indentation in addition to the indentation of the replace: key“. However, it only has two, which makes the YAML parser immediately drop out of block scalar parsing mode. The following error results from the YAML parser trying to interpret what you intend to be the block scalar's content as part of the YAML structure.
I suggest doing:
replace: |-2
name: 'traefikExporter',
enabled: true,
to give the block scalar 2 space in front of each line (which seems to be what you want) and also to remove the trailing newline (with the -).
I've browsed similar questions and believe i've applied all that i've been able to glean from answers.
I have a .yml file where as far as I can tell each element is formatted identically. And yet according to YamlLint.com
(<unknown>): mapping values are not allowed in this context at line 119 column 16
In this case, line 119 is the line containing the second instance the word "transitions" below. That I can tell each element is formatted identically. Am I missing something here?
landingPage:
include: false
transitions:
-
condition:location
nextState:location
location:
include:false
transitions:
-
condition:excluded
nextState:excluded
excluded:
include:false
transitions:
-
condition:excluded
nextState: excluded
-
condition:age
nextState:age
You cannot have a multiline plain scalar, such as your include:false transitions be the key to a mapping, that is why you get the mapping values not allowed in this context error.
Either you forgot that you have to have a space after the value indicator (:), and you meant to do:
include: false
transitions:
or you need to quote your multi-line scalar:
'include:false
transitions':
or you need to put that plain scalar on one line:
include:false transitions:
please note that some libraries do not allow value indicators in a plain scalar at all, even if they are not followed by space
I fixed this for myself by simply realizing I had indented a line too far, and un-indenting it.
we need to use space before ":"
Then it will excecute
check the yaml script in below
http://www.yamllint.com/
There are couple of issues in the yaml file, with yaml files it gets messy, fortunately it can be identified easily with tools like yaml lint
Install it
npm install -g yaml-lint
Here is how you can validate
E:\githubRepos\prometheus-sql-exporter-usage\etc>yamllint prometheus.yaml
√ YAML Lint successful.
For me the problem was a unicode '-' from a cut and paste. Visualy it looked OK, but the character was 'EN DASH' (U+2013) instead of 'HYPHEN MINUS' (U+002D)
In mine case it was the space after the : in a value:
query-url: https://blabla.com/blabla?label=blabla: blabla
To fix:
query-url: https://blabla.com/blabla?label=blabla:%20blabla
Or:
query-url: "https://blabla.com/blabla?label=blabla: blabla"
If you are using powershell and have copied the cat command, it won't work properly (I'm guessing it is encoding the content in some way). Instead of using "$(cat file.yaml)" you should use $(Get-Content file.yaml -Raw) without the quotes.
Really annoying!
In my case if was some odd disappearing of the initial formatting of the initial chart that was copied in Intellij Idea. It was possible to gfigure out with text-compare tool only:
So, when you do your copy and paste in your IDE, please double check is what you have copied is exactly what you paste, aren't some additional spaces were added.
Syntax coloring is very useful, but I have problems with it in Sublime Text 2. In particular, when a line beginning with a command (like ALLOCATE in Fortran) is after one or more commented line, the command changes the color as if it is a variable.
ALLOCATE(XYZ%CC(3,NC(1),NC(2),NC(3)))
!ALLOCATE(XYZ%CV(3,NF(1),NF(2),NF(3)))
ALLOCATE(XYZ%CV(3,NC(1)+1,NC(2)+1,NC(3)+1))
This can be corrected by replacing Packages/Fortran/Syntaxes/Fortran - Modern.tmLanguage with this version. To use, save the raw version of the file in the gist as Fortran - Modern.tmLanguage. Next, in Sublime, select Preferences → Browse Packages… to open the Packages folder in your operating system's file manager. Open the Fortran/Syntaxes folder and replace the existing Fortran - Modern.tmLanguage file with the new one. Also, make sure you delete Fortran - Modern.tmLanguage.cache, otherwise the changes won't take effect.
Then end result is now:
in contrast with the original behavior:
Why the change was needed, and how it works
I used PackageDev to translate the XML-based .tmLanguage file into a much more readable YAML-based format. In it, there were two sections defining comments, one for comment blocks starting with !-:
- begin: (^[ \t]+)?(?=!-)
beginCaptures:
'1': {name: punctuation.whitespace.comment.leading.ruby}
end: (?!\G)
patterns:
- name: comment.line.exclamation.mark.fortran.modern
begin: '!-'
beginCaptures:
'0': {name: punctuation.definition.comment.fortran}
end: \n
patterns:
- match: \\\s*\n
and one for comments just beginning with !:
- begin: (^[ \t]+)?(?=!)
beginCaptures:
'1': {name: punctuation.whitespace.comment.leading.ruby}
end: (?!\G)
patterns:
- name: comment.line.exclamation.fortran.modern
begin: '!'
beginCaptures:
'0': {name: punctuation.definition.comment.fortran}
end: \n
patterns:
- match: \\\s*\n
This additional complexity is unnecessary and confusing, and not even the right way of doing it. There is no need for a punctuation.whitespace.comment.leading scope (and where did that .ruby suffix come from?), and the regexes for the actual comment block were overly complex and incorrect.
I removed both of the above sections and replaced them with this simple section:
- name: comment.line.exclamation.fortran.modern
match: (!-?).*$\n?
captures:
'1': {name: punctuation.definition.comment.fortran}
The regex is quite straightforward: capture the first group in parentheses - a ! optionally followed by a -, and scope it as the comment symbol. Then, match anything up to the end of the line ($), optionally terminated by a newline character. I'm not even completely sure of how the previous regexes worked...
An ampersand at the start of a YAML entry is normally seen as a label for a set of data that can be referenced later. How do you escape a legitimate ampersand at the start of a YAML entry. For example:
---
- news:
news_text: “Text!’
I am looking to not have &ldquo be a label within the yaml file, but rather when I get parse the YAML file to have the news_text come back with the “ in the entry.
Just put quotes around the text
require 'yaml'
data = <<END
---
- news:
news_text: "“Text!’"
END
puts YAML::load(data).inspect
# produces => [{"news"=>{"news_text"=>"“Text!’"}}]
You probably can enclose the text in quotes:
---
- news:
news_text: "“Text!’"
Besides, you can probably just as well use the proper characters there:
---
- news:
news_text: “Text!’
Putting escapes specific to a totally different markup language into a document written in another markup language seems ... odd to me, somehow.
Or you could put the string on the next line, if you put a '>' or '|' at the spot where the string used to be. Using the '|' character your parser will keep your custom line breaks, while '>' turns it into one long string, ignoring line breaks.
- news:
news_text: >
“Text!’
Putting the entire string in single quotes would do what you want:
---
- news:
news_text: '“Text!’'
But, I think that any yaml library should be smart enough to do that for you?