-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Git Files] Add Git Files package #1126
Changes from 2 commits
b44fe8f
d802d3a
9ad0f06
ea2ac5a
f257c68
43e11f3
d97a1ab
9404e60
d01adf5
2a119a9
f938bd1
ec509be
16cf43b
bff54a5
9dc50fb
98116c9
3863bf2
27363ca
1e6d44d
13897a1
2ecbf9e
4752d69
28d8bb2
a69b86d
cacce71
4d7b60e
92763c4
52343d1
f35380e
9596e7c
86efdd6
940d1bf
c4d6758
16fb208
a8be2f0
0f5fd79
9b22879
9c6f12a
f952391
99da69a
937c7de
d4d952d
83f303b
3cc7a7b
161b6a7
437c532
dda56a0
ec25ba2
918e1de
01320be
ce37d63
a4d64f3
09c90ce
d068d7d
4195122
d1d2dd7
bf92620
cbfbe7e
cc7df2f
c6a2a70
b901cc8
a81f4e3
25b3658
1d17e49
689b737
23e9200
bf103aa
1a920e1
92dff27
f97ebd3
1a077a3
942d62e
462873a
7e2fd09
2d9b9f9
20445ee
aeb786b
965b015
4896438
b19e70c
9a78289
ed8c6e7
6bd9ada
731e25f
d30a0aa
c8d8dee
7e41d5b
0bcb500
26f8095
1701313
a8d5928
6af5bfe
0485882
c783cc9
85116e0
a987aff
7aa5ffc
b38ad96
4de96c7
7c10705
00e10a8
bcd2798
065536f
c2fee71
a255364
758cc44
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
<?xml version="1.0" encoding="UTF-8"?> | ||
<plist version="1.0"> | ||
<dict> | ||
<key>name</key> | ||
<string>Comments</string> | ||
<key>scope</key> | ||
<string>source.gitcommit, source.gitconfig, source.gitrebase</string> | ||
<key>settings</key> | ||
<dict> | ||
<key>shellVariables</key> | ||
<array> | ||
<dict> | ||
<key>name</key> | ||
<string>TM_COMMENT_START</string> | ||
<key>value</key> | ||
<string># </string> | ||
</dict> | ||
</array> | ||
</dict> | ||
</dict> | ||
</plist> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
<snippet> | ||
<content><![CDATA[ | ||
[${1:section}] | ||
$0 | ||
]]></content> | ||
<tabTrigger>section</tabTrigger> | ||
<scope>source.gitconfig</scope> | ||
<description>[section]</description> | ||
</snippet> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
<?xml version="1.0" encoding="UTF-8"?> | ||
<plist version="1.0"> | ||
<dict> | ||
<key>name</key> | ||
<string>Symbol List</string> | ||
<key>scope</key> | ||
<string>meta.brackets.gitconfig</string> | ||
<key>settings</key> | ||
<dict> | ||
<key>showInSymbolList</key> | ||
<integer>1</integer> | ||
</dict> | ||
</dict> | ||
</plist> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
%YAML 1.2 | ||
--- | ||
# Highlight regular git commits, merge commits, and tags. | ||
|
||
name: Git Commit | ||
file_extensions: | ||
- COMMIT_EDITMSG | ||
- MERGE_MSG | ||
- TAG_EDITMSG | ||
scope: text.gitcommit | ||
|
||
contexts: | ||
prototype: | ||
- include: comments | ||
|
||
main: | ||
- include: commit-message | ||
|
||
branch-line: | ||
- match: \bOn branch\s+(.*) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How to handle localized comments? I just saw git for linux presenting my the comment in german language. So highlighting fails. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there aren't that many translation files: https://github.com/git/git/tree/master/po There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @FichteFoll: The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, my first line is the search string to look for in the |
||
captures: | ||
1: support.type.branch-name.gitcommit | ||
|
||
change: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is an interesting context, but can be improved. For example, highlight the |
||
- match: (new file|modified|deleted)\s*(:)\s*(.*) | ||
captures: | ||
1: keyword.change-list.change.gitcommit | ||
2: punctuation.separator.change.gitcommit | ||
3: keyword.change-list.file.gitcommit | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd rather tend to scope that as normal The whole construct could be handled as key-value pair in general, I think. |
||
|
||
change-list: | ||
- include: change-list-header | ||
- include: change | ||
|
||
change-list-header: | ||
- match: '\bChanges to be committed\s*(:)' | ||
scope: keyword.change-list.heading.gitcommit | ||
captures: | ||
1: punctuation.separator.change-list.gitcommit | ||
|
||
comments: | ||
- match: '#' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Have you thought about this?
Does There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤔 Hmm, currently it's matching as a value, ever since I changed this match from I'm not sure if this is the correct behavior, or if it should match as a comment. If it should be a comment, I could change There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went ahead and tested this here (git version 2.11). With
the output of
is
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Moreover,
|
||
scope: punctuation.definition.comment.gitcommit | ||
push: | ||
- meta_scope: comment.line.gitcommit | ||
- match: \n | ||
pop: true | ||
- include: change-list | ||
- include: branch-line | ||
- include: date-line | ||
|
||
commit-message: | ||
# this absurd regex is necessary to: | ||
# 1. match comments in the subject line | ||
# 2. only style the first 50 chars in the subject line | ||
- match: ([^#\n]{,50})[^#\n]*((#).*$)? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I can see from a couple of
The commit message in EDIT_COMMITMSG says: "Lines starting with '#' will be ignored" Furthermore why do you style the 50 characters only? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
captures: | ||
1: string.unquoted.subject-line.gitcommit markup.heading.gitcommit | ||
2: comment.line.gitcommit | ||
3: punctuation.definition.comment.gitcommit | ||
push: | ||
# enforce empty line following subject line | ||
- match: \n | ||
push: | ||
- match: \n | ||
pop: true | ||
- match: '.+$' | ||
scope: invalid.missing-newline.gitcommit | ||
# everything left that isn't a comment is the commit message | ||
- match: '[^#]*' | ||
scope: text.plain.commit-message.gitcommit | ||
push: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When do we pop from this push? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question! This is kinda hacky. The goal is to enforce the empty-line-after-subject rule This is done with the previous If there's a better, less hacky, way of achieving this, please let me know! vim's highlighting of commits |
||
- match: '[^#]*' | ||
scope: text.plain.commit-message.gitcommit | ||
|
||
# apply a meta scope to the commit date | ||
date-line: | ||
- match: \bDate\s*(:)\s*(.*) | ||
captures: | ||
1: punctuation.separator.date.gitcommit | ||
2: meta.commit-date.gitcommit |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,206 @@ | ||
%YAML 1.2 | ||
--- | ||
# Syntax based on documentation here: | ||
# https://git-scm.com/docs/git-config#_syntax | ||
|
||
name: Git Config | ||
file_extensions: | ||
- gitconfig # /etc/gitconfig | ||
- .gitconfig # ~/.gitconfig | ||
first_line_match: ^\[core\] # .git/config files always start with [core] | ||
scope: source.gitconfig | ||
|
||
variables: | ||
escape_char: \\"bnt | ||
section_name: '[\w.-]+(?=[\s\]])' # lookahead catches missing space, e.g. color"branch". | ||
space_or_eol: (?=(?:\s|$)) # makes values on last line match properly | ||
variable_name: '[a-zA-Z][\w-]*' | ||
zero_to_255: 25[0-5]|2[0-4][0-9]|1\d\d|[1-9][0-9]|[0-9] | ||
|
||
contexts: | ||
prototype: | ||
- include: comments | ||
|
||
main: | ||
- include: section | ||
|
||
boolean: | ||
# 0 and 1 are omitted due to mismatches (e.g. "log -1", "HEAD~1"). They will | ||
# be matched as unquoted strings instead. | ||
- match: \b(?:yes|true|on|off|no|false){{space_or_eol}} | ||
scope: constant.language.gitconfig | ||
|
||
color: | ||
- include: color-named # red, blue, green | ||
- include: color-attribute # bold, italic, underline | ||
- include: color-numeric # 0-255 | ||
|
||
color-attribute: | ||
- match: \b(?:no-?)?(?:ul|strike|reverse|italic|dim|bold|blink){{space_or_eol}} | ||
scope: support.constant.color-attribute.gitconfig | ||
|
||
color-named: | ||
- match: \b(?:yellow|white|red|normal|magenta|green|cyan|blue|black|auto){{space_or_eol}} | ||
scope: support.constant.color.gitconfig | ||
|
||
color-numeric: | ||
- match: '\b(?:{{zero_to_255}}){{space_or_eol}}' | ||
scope: constant.other.color.rgb-value.gitconfig | ||
|
||
comments: | ||
- match: '[#;]' | ||
scope: punctuation.definition.comment.gitconfig | ||
push: | ||
- meta_scope: comment.line.gitconfig | ||
- match: $\n? # consume newline so completions aren't shown at EOL when | ||
pop: true # typing comments | ||
|
||
# The only valid escapes: '\b', '\n', '\t', '\"', '\\'. | ||
escape: | ||
- include: trailing-slash | ||
- match: \\[^{{escape_char}}] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We'd probably try to match valid escapes first? |
||
scope: invalid.illegal.escape.gitconfig | ||
- match: \\[{{escape_char}}] | ||
scope: constant.character.escape.gitconfig | ||
|
||
illegal-newline: | ||
- match: \n | ||
scope: invalid.illegal.gitconfig | ||
|
||
illegal-slash: | ||
- match: \\ | ||
scope: invalid.illegal.gitconfig | ||
|
||
# changed = red | ||
# untracked = bold green | ||
key-color-pair: | ||
- match: ^\s*({{variable_name}})\s*(\=) | ||
captures: | ||
1: variable.other.readwrite.gitconfig | ||
2: keyword.operator.assignment.gitconfig | ||
push: | ||
- meta_scope: meta.key-value-pair.gitconfig | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By convention this needs to be: You can have a look into the JSON syntax or https://github.com/SublimeText/PackageDev/tree/master/Package files, which handle it very well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The JSON syntax doesn't handle this yet, but you can check out the pull request for it here: #862 |
||
- meta_content_scope: meta.value.gitconfig | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you explain what There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's the value part of a key-value pair, basically. The corresponding RFC issue where this was discussed is #421. |
||
- match: '(?=^\s*{{variable_name}}\s*\=)' # next key-value pair | ||
pop: true | ||
- match: (?=^\s*\[) # start of new section | ||
pop: true | ||
- include: color | ||
|
||
# key = val | ||
key-value-pair: | ||
- match: ^\s*({{variable_name}})\s*(\=) | ||
captures: | ||
1: variable.other.readwrite.gitconfig | ||
2: keyword.operator.assignment.gitconfig | ||
push: | ||
- meta_scope: meta.key-value-pair.gitconfig | ||
- meta_content_scope: meta.value.gitconfig | ||
- match: '(?=^\s*{{variable_name}}\s*\=)' # next key-value pair | ||
pop: true | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This match+pop is a bit weird. [x]
a = b
c
d = e
f =
It seems values really end when a newline is encountered. Except of course when we're in a quoted string. But the syntax now suggests that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be resolved by my latest push. |
||
- match: (?=^\s*\[) # start of new section | ||
pop: true | ||
- include: value | ||
|
||
# [section "subsection"] | ||
section-header: | ||
- match: \[ | ||
scope: punctuation.definition.section.begin.gitconfig | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm fine with punctuation.definition if you think it suits better. |
||
push: | ||
- meta_scope: meta.brackets.gitconfig | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe someone could help clarify the
All of that is quite mixed up here. I'd suggest to handle a INI file section the same way as JSON object ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I changed the scope from |
||
- match: \] | ||
scope: punctuation.definition.section.end.gitconfig | ||
pop: true | ||
- include: illegal-newline # complain if '[' and ']' on separate lines | ||
- include: illegal-slash | ||
- include: subsection-name | ||
- include: section-name | ||
- include: stray-bracket | ||
|
||
# A section is a [section header] and the list of key-value pairs under it. | ||
# | ||
# [section "subsection"] | ||
# key1 = value1 | ||
# key2 = value2 | ||
section: | ||
# [color] subsections are matched separately, because they are the only | ||
# sections that take colors for values. | ||
- include: section-color # e.g. [color "branch"], [color "status"] | ||
- include: section-other | ||
|
||
# We only want to match color values under these subsections: | ||
# [color "branch"] | ||
# [color "diff"] | ||
# [color "interactive"] | ||
# [color "status"] | ||
# Note that this does not match [color] (without the subsection). This is | ||
# because [color] doesn't actually take color values. | ||
section-color: | ||
- match: ^\s*(?=\[\s*color\s+\") | ||
push: | ||
- match: (?=^\s*\[) # start of new section | ||
pop: true | ||
- include: section-header | ||
- include: key-color-pair | ||
|
||
section-name: | ||
- match: '{{section_name}}' | ||
scope: entity.name.gitconfig | ||
|
||
# section-other matches all sections except [color "subsection"]. | ||
section-other: | ||
- match: ^\s*(?=\[) | ||
push: | ||
- match: (?=^\s*\[) # start of new section | ||
pop: true | ||
- include: section-header | ||
- include: key-value-pair | ||
|
||
stray-bracket: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a general question about the structure of syntax files: Is it really useful to split the rules in such little parts, that we end up in single such simple once used matches? With such rules being used several times, I'd answer YES, but why doing so for uniquely used matches. The scope-name already tells us its usage "stray-bracket" and a comment would do so, too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For code, having functions for self-documenting code is usually good practice, but as you mentioned, the scope name is very self-documenting in syntax definitions as well, so that doesn't really hold here. |
||
- match: \] | ||
scope: punctuation.definition.section.end.gitconfig invalid.illegal.stray-bracket.gitconfig | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Everything after the closing bracket of a section line is illegal, not only a stray bracket, isn't it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @deathaxe Does that include comments? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No it does not. Git allows comments at the end of each line. Comments are handled as The rule should than just look like |
||
|
||
string: | ||
- match: '"' | ||
scope: punctuation.definition.string.begin.gitconfig | ||
push: | ||
- meta_include_prototype: false | ||
- meta_scope: string.quoted.double.gitconfig | ||
- match: '"' | ||
scope: punctuation.definition.string.end.gitconfig | ||
pop: true | ||
- include: escape | ||
- include: illegal-newline # newlines only permitting after trailing \ | ||
|
||
# [section "subsection"] | ||
# Subsections are not normal strings. Escapes (e.g. \", \t) and trailing | ||
# slashes are not recognized. Newlines are illegal. | ||
subsection-name: | ||
- match: '"' | ||
scope: punctuation.definition.string.begin.gitconfig | ||
push: | ||
- meta_include_prototype: false | ||
- meta_scope: string.quoted.double.gitconfig | ||
# '\' is legal in a subsection name, but in front of the trailing '"' | ||
# it prevents the '"' from terminating the string. \" is not an escape. | ||
# It is still interpreted as two characters. | ||
- match: \\" # no scope needed | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is there no constant.character.escape needed here?
Sure, I have to escape it in my shell, but that's a limitation of my particular shell. It'll be passed to git as the (raw) string There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've been playing around with escapes in subsection names, and discovering some strange behavior. Every character can be "escaped".
$ git config --get x.foo.a
hello Traditional escapes like - match: \\.
scope: constant.character.escape.gitconfig ...but then users will see The only time when To avoid user confusion, I think we should discourage - match: \\[\\"]
scope: constant.character.escape.gitconfig
- match: \\
scope: invalid.unnecessary-escape.gitconfig What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure how many color schemes would target |
||
- match: '"' | ||
scope: punctuation.definition.string.end.gitconfig | ||
pop: true | ||
- include: illegal-newline | ||
|
||
# Trailing slashes can be used to break up long lines. '\' is only legal at | ||
# the end of a line, or in an escape such as '\"'. Anywhere else it will cause | ||
# a fatal parser error. Comments are not permitted after a trailing slash. | ||
trailing-slash: | ||
- match: (\\)\s*$ | ||
captures: | ||
1: constant.character.escape.gitconfig | ||
|
||
value: | ||
- include: escape # \", \\, \t | ||
- include: string | ||
- include: boolean # true, yes, on, off, no, false | ||
- match: \S # match most values | ||
scope: string.unquoted.value.gitconfig |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,58 @@ | ||
%YAML 1.2 | ||
--- | ||
# Highlight interactive rebase text (git rebase -i). | ||
|
||
name: Git Rebase | ||
file_extensions: | ||
- git-rebase-todo | ||
first_line_match: '^(?:pick|squash|reword|fixup|exec|edit|drop) \h{7,} ' | ||
scope: source.gitrebase | ||
|
||
variables: | ||
hash: \h{7,} | ||
|
||
contexts: | ||
prototype: | ||
- include: comments | ||
|
||
main: | ||
- include: commit | ||
|
||
comments: | ||
- match: '#' | ||
scope: punctuation.definition.comment.gitrebase | ||
push: | ||
- meta_scope: comment.line.gitrebase | ||
- match: \n | ||
pop: true | ||
- include: rebase-msg | ||
|
||
# e.g. pick d284bb2 Initial commit | ||
commit: | ||
- match: ^\s*(squash|reword|pick|fixup|exec|edit|drop|x|s|r|p|f|e|d)[\t ] | ||
captures: | ||
1: storage.type.edit.gitrebase | ||
push: | ||
- meta_scope: meta.commit.gitrebase | ||
- match: \n | ||
pop: true | ||
- match: \b({{hash}})\s # e.g. d284bb2 | ||
captures: | ||
1: constant.numeric.hex.hash.gitrebase | ||
push: | ||
- meta_content_scope: text.plain.commit-msg.gitrebase | ||
- match: $ | ||
pop: true | ||
|
||
# e.g. Rebase 9e73d21..6746220 onto 9e73d21 (2 commands) | ||
# highlight the hashes in this comment | ||
rebase-msg: | ||
- match: '\bRebase\s+' | ||
push: | ||
- meta_scope: meta.rebase-msg.gitrebase | ||
- match: '$' | ||
pop: true | ||
- match: '\b{{hash}}\b' | ||
scope: constant.numeric.hex.hash.gitrebase | ||
- match: \.\. | ||
scope: keyword.operator.commit-range.gitrebase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Including comments as prototype is useless as they must only start at the beginning of a line and must not be matched within a commit message line. Therefore the following construct is enough: