Skip to content
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

[Diff] Refactor for Diff3, Git, and conflicts #4111

Open
wants to merge 129 commits into
base: master
Choose a base branch
from

Conversation

michaelblyons
Copy link
Collaborator

@michaelblyons michaelblyons commented Dec 7, 2024

Big refactor of Diff syntax according to the GNU and SVN documentation. New Git Diff syntax, also used by Git Log.

Thank you 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)
    • When the normal Diff syntax detects the "magic" first line, it delegates out to Git Diff instead.
  • New support for
    • Diff3 formats
    • Conflict sections
    • "Combined" unified diffs, only in Git Diff

Potentially controversial

  • Conflicts somewhat with [Common] Add git conflict marker highlighting #4047, but should now be nearly compatible.
  • storage.modifier distinguishes between the two Git file modes (namely 644 and 755)
  • Markup scopes color the ++++---- and similar, even though they're not actually markup.
  • Users and emails are delegated out to Mailmap.
  • Whatever you noticed.

Also include their file modes

[Diff] Change file mode highlighting

[Diff] Loosen file mode match
Includes the Git Commit Message stuff, because that's what it is.
[Diff] Empty file hash
Technically, this is called the "signature."
@michaelblyons

This comment was marked as resolved.

@jrappen
Copy link
Contributor

jrappen commented Dec 20, 2024

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

@michaelblyons
Copy link
Collaborator Author

michaelblyons commented Dec 20, 2024

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.

@deathaxe
Copy link
Collaborator

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

@michaelblyons
Copy link
Collaborator Author

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.

deathaxe
deathaxe previously approved these changes Dec 27, 2024
@michaelblyons michaelblyons changed the title [Diff] Organize contexts, add tests, support Git patch emails [Diff] Refactor for Diff3, Git, and conflicts Dec 28, 2024
This commit...

1. adds more detailed scopes to conflict markers
2. adds conflicting blocks to symbol list
3. removes some multi-push and lookaheads
4. adds support for indented fenced diff code blocks
   (allow markers to be preceded by whitespace)
deathaxe
deathaxe previously approved these changes Jan 9, 2025
Unfortunately, line ranges (which start at BOL) cannot be tested.
deathaxe
deathaxe previously approved these changes Jan 12, 2025
It causes odd behavior when BOL is changed to allow spaces
deathaxe
deathaxe previously approved these changes Jan 29, 2025
if you're already in the Git Diff syntax
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I loaded a patch from patchwork.kernel.org and I was surprised not to get the full highlighting. It did not have a "magic" date. If the more lenient git_first_line should be bumped to Diff (Basic), let me know.

Comment on lines +181 to +187
git_first_line: |-
{{bol}}(?x:
From [ ] \w+@z [ ]
Thu [ ] Jan [ ]{2} 1 [ ] 00:00:00 [ ] 1970 # git-send-email
| From [ ] {{git_hash_full}} [ ]
Mon [ ] Sep [ ] 17 [ ] 00:00:00 [ ] 2001 # git-format-patch
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How magic is the date? Are these really only those two days?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The git-format-patch one is listed in the documentation. The git-send-email one I saw live in a different document online (context at dandavison/delta#1863), but does not appear in docs.

It wasn't until today that I saw a random date that I think matches the commit date.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As docs explicitly state about those fixed dates as "magic number" to separate patches from normal mails, we should probably keep going with them as is.

Copy link
Collaborator Author

@michaelblyons michaelblyons Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable to me. The only counter argument I have in favor of putting the variable in Diff (Basic) is that you're already in the Diff syntax. Is "in the Diff syntax" and "first line is MBOX style" enough of a heuristic to have the Git Diff highlighting activate?

I wouldn't want to loosen the first_line_match.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not my every day use case. So it is hard to judge. If such patch files however use *.patch extension, I am uncertain about use of Git Diff specific git_first_line as file extensions are preferred for highlighting, so normal Diff would win.

It would only apply to patch files without file extensions.

So whatever headers should be supported, they seem useful only in Diff (Basic).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So whatever headers should be supported, they seem useful only in Diff (Basic).

Maybe you forget that Diff (Basic) does that thing where if you actually have a Git Diff, it sends to Git Diff syntax instead. I don't have a problem making the git_first_line variable more lenient in Diff (Basic).

I am a little wary of changing the first_line_match in case you (a) have no MBOX syntax, and (b) load an MBOX file. At this point, with a lenient first_line_match, one of the diff syntaxes would load and try to highlight as a Git Diff. This may not actually be a bad thing since it marks email headers, but could conceivably freak out for multi-email MBOX files.

But if Sublime Text has chosen Diff or Git Diff by file extension, I think it would be polite to load up the Git Diff variant if the first line loosely matches.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am probably not the right one to finally judge that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Syntax significant T: enhancement Improvement of existing language features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants