[Diff] Organize contexts, add tests, support Git patch emails

[michaelblyons]

This started out as an attempt to use parts of an email syntax I wrote to support front matter in Git patch emails. It kind of ballooned after that to include a big refactor of the base Diff syntax according to the GNU patch spec.

I would not claim this is perfect, but I'd like some other eyes on it. Edit: Much improved. Thanks to the reviewers!

Notable changes

• Lots of documentation links
• Lots of new tests, mostly pulled from relevant documentation
• Some scope tweaking, but preserving the stacking from [Diff] Make scopes consistent (backwards compatible) #2178 for backwards-compatibility
• New syntax for Git Diff emails (git am and git format-patch)
• New support for
  • Diff3 formats
  • Conflict sections
  • "Combined" unified diffs, only in Git Diff

Potentially controversial

• This PR conflicts somewhat with [Common] Add git conflict marker highlighting #4047, but I think that PR also has great merits. I made a "conflict" syntax separate from the diff syntax, but if other people have strong feelings about conflict markers being part of Diff.sublime-syntax, I'd consider trying to bring it in. Edit: I pulled it back into main Diff
• When the normal Diff syntax detects the "magic" first line, it delegates out to Git Diff instead. Edit: This now happens in a way that doesn't add syntax bloat.
• I use storage.modifier to distinguish between the two Git file modes (namely 644 and 755)
• I use markup scopes to color the ++++---- and similar, even though they're not actually markup.
• I never know what scopes to use for dates.
• I cheated by delegating users/emails out to Mailmap.
• Whatever you noticed. 😛

Requested changes

• Fix unit tests
• More whitespace
• Move variables to EOF
• Move boring contexts to bottom of contexts
• More named contexts to support inheritance
• Investigate i10n
  • I haven't found any equivalents in the German po file for stuff I've added scopes to. If someone knows differently, please provide examples.
• Simplify line endings
• Base syntax for Diff and Git Diff.

[michaelblyons]

I've brought Conflict.sublime-syntax back in, along with a conservative side-by-side highlighter. A more risky side-by-side syntax at michaelblyons#10

[jrappen]

let us know when/if you need any review or feedback 😁

[michaelblyons]

let us know when/if you need any review or feedback 😁

Haha. Sorry if you're flooded in notifications. The PR is a lot better after you and DeathAxe's reviews. I think if you're looking for something, check my PRs to this PR (michaelblyons#11 and michaelblyons#10) and decide if you care about any of the things in the "controversial" heading in OP.

Thanks again.

[jrappen]

Maybe you could add an empty line between meta patterns (https://www.sublimetext.com/docs/syntax.html#meta-patterns) and the rest in your named contexts.

Compare:

contexts:
  name:
    - meta_include_prototype: false
    - meta_scope: one
    - meta_content_scope: two
    - include: three
    - include: four

vs.

contexts:
  name:
    - meta_include_prototype: false
    - meta_scope: one
    - meta_content_scope: two

    - include: three
    - include: four

Makes it easier to read.

[jrappen]

On a related note, when applying multiple scopes:

Compare:

contexts:
  name:
    - meta_include_prototype: false
    - meta_scope: one two three
    - meta_content_scope: four
    - include: five
    - include: six

vs.

contexts:
  name:
    - meta_include_prototype: false
    - meta_scope: >-
        one
        two
        three
    - meta_content_scope: four

    - include: five
    - include: six

Makes it easier to read and makes for easier to understand diffs in the git history of this repo.

[deathaxe]

Empty lines between contexts is ok, but starting arbritary emptly lines between patterns is too much.

[michaelblyons]

There are places where I have considered newlines in stacked scopes, but I am not planning to add an empty line between meta and includes. PackageDev scoping is sufficient to make that distinction very obvious.