Leading 0 GUID parse fix

[AndrewFalanga]

Hi I found when using this that some editors put GUIDs into the files by omitting leading 0's in the first 4 bytes. This modification touches the regex so that it works with hex strings of 7 or 8 characters instead of 8 only.

I hope that I'm properly following etiquette on GitHub for this.

[gemini-code-assist]

Hello @AndrewFalanga, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request. This PR addresses an issue where the Vim syntax highlighting for UEFI files (.dec, .dsc, .fdf) failed to correctly parse GUIDs when the first segment omitted leading zeros (e.g., 1234567-.... instead of 01234567-....). The changes modify the regular expressions used to identify GUIDs in these files to correctly match segments with either 7 or 8 hexadecimal characters, thus fixing the parsing for such cases. Additionally, the highlighting color for GUIDs has been changed from gold to purple.

Highlights

• GUID Parsing Fix: Updates the regular expressions in the Vim syntax files (uefidec.vim, uefidsc.vim, uefifdf.vim) to correctly parse GUIDs where the first 4-byte segment might omit leading zeros, allowing matches for 7 or 8 hexadecimal characters.
• Syntax Highlighting Update: Introduces a new purple highlight color (x220_Purple) and changes the highlighting for parsed GUIDs in .dec, .dsc, and .fdf files from gold (x220_Gold1) to this new purple color.

Changelog

Click here to see the changelog

• after/syntax/c.vim
  • Added definition for highlight color x220_Purple.
• syntax/uefidec.vim
  • Modified decRegistryFormatGUID regex to accept 7 or 8 hex characters in the first segment.
  • Modified decCFormatGUID regex (start pattern) to accept 7 or 8 hex characters in the first segment.
  • Added definition for highlight color x220_Purple.
  • Changed highlight link for decCFormatGUID and decRegistryFormatGUID from x220_Gold1 to x220_Purple.
• syntax/uefidsc.vim
  • Modified decRegistryFormatGUID regex to accept 7 or 8 hex characters in the first segment.
  • Modified decCFormatGUID regex (start pattern) to accept 7 or 8 hex characters in the first segment.
  • Added definition for highlight color x220_Purple.
  • Changed highlight link for decCFormatGUID and decRegistryFormatGUID from x220_Gold1 to x220_Purple.
• syntax/uefifdf.vim
  • Modified decRegistryFormatGUID regex to accept 7 or 8 hex characters in the first segment.
  • Modified decCFormatGUID regex (start pattern) to accept 7 or 8 hex characters in the first segment.
  • Added definition for highlight color x220_Purple.
  • Changed highlight link for decCFormatGUID and decRegistryFormatGUID from x220_Gold1 to x220_Purple.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

Thank you for this contribution! The regex change to support 7 or 8 hex characters for the first part of GUIDs is a good improvement and directly addresses the issue of editors omitting leading zeros.

I have one point of feedback regarding the new highlight color definition x220_Purple that's used for these GUIDs, detailed in the comments below.

Summary of Findings

• GUID Regex Fix: The change from \x\{8\} to \x\{7,8\} in GUID matching regexes correctly allows for parsing GUIDs with an omitted leading zero in their first segment. This is a good functional improvement.
• Highlight Color Naming/Definition: The new highlight group x220_Purple uses ctermfg=220 (which is Gold1 in xterm palettes) and guifg=#161f7e (a dark purple). The name x220_Purple might be misleading as ctermfg=220 is not purple, and this setup creates a divergence in color between terminal (gold) and GUI (purple) for GUIDs. This differs from the pattern of harmonious ctermfg/guifg colors seen in other definitions like x203_IndianRed1 or x220_Gold1. Clarification or adjustment to the name or ctermfg value is suggested.

Merge Readiness

The core regex fix for GUID parsing is well-implemented and a welcome change. However, there's a medium-severity concern regarding the naming and ctermfg choice for the new x220_Purple highlight group. This could lead to confusion or an unexpected appearance in terminals if a consistent purple color was intended across both terminal and GUI environments. Addressing this point by clarifying the intent or adjusting the definition would improve the overall clarity and consistency of the syntax highlighting.

I am recommending changes to address this aspect. As an AI reviewer, I cannot approve pull requests, so please ensure this PR receives further human review and approval before merging.

[gemini-code-assist]

The new highlight group x220_Purple uses ctermfg=220 (which is a gold/yellow color like Gold1 in standard xterm 256-color palettes) and guifg=#161f7e (a dark purple).
This means that items highlighted with x220_Purple will appear purple in GUIs but gold in terminals (as ctermfg=220 is used).

This setup differs from other color definitions in the project, such as x203_IndianRed1 (ctermfg=203 is reddish, guifg is red) or x220_Gold1 (ctermfg=220 is gold, guifg is gold). In those cases, ctermfg and guifg represent similar colors, and the name x<cterm-value>_<ColorName> reflects this visual harmony.
With x220_Purple, the ctermfg=220 (gold) and the "Purple" part of the name (reflecting the guifg) are dissimilar, breaking this pattern.

Was this difference in terminal versus GUI color intentional?

• If the goal is for the highlighted items to appear purple in both GUI and terminal (where possible), consider changing ctermfg to a purple terminal color code. For example:

  hi x93_Purple ctermfg=93 guifg=#161f7e " Example: ctermfg 93 is a dark purple

  This would also involve updating the name from x220_Purple to x93_Purple (or similar) and ensuring any hi def link statements that use this color are updated accordingly.

• If the intent is indeed for items to be gold in terminals and purple in GUIs, the current definition achieves this. However, the name x220_Purple could be a bit misleading. In this case, perhaps adding a comment to the definition explaining this specific choice would be helpful for future maintainers?

Could you clarify the intended appearance, especially for terminals?

hi x93_Purple ctermfg=93 guifg=#161f7e

[gemini-code-assist]

The new highlight group x220_Purple uses ctermfg=220 (which is a gold/yellow color like Gold1 in standard xterm 256-color palettes) and guifg=#161f7e (a dark purple).
This means that GUIDs highlighted with x220_Purple will appear purple in GUIs but gold in terminals (as ctermfg=220 is used, same as the previous x220_Gold1).

This setup differs from other color definitions in the project, such as x203_IndianRed1 (seen in after/syntax/c.vim, where ctermfg=203 is reddish, guifg is red) or the existing x220_Gold1 (where ctermfg=220 is gold, guifg is gold). In those cases, ctermfg and guifg represent similar colors, and the name x<cterm-value>_<ColorName> reflects this visual harmony.
With x220_Purple, the ctermfg=220 (gold) and the "Purple" part of the name (reflecting the guifg) are dissimilar, breaking this pattern.

Was this difference in terminal versus GUI color intentional?

• If the goal is for GUIDs to appear purple in both GUI and terminal (where possible), consider changing ctermfg to a purple terminal color code. For example:

  hi x93_Purple ctermfg=93 guifg=#161f7e " Example: ctermfg 93 is a dark purple

  This would also involve updating the name from x220_Purple to x93_Purple (or similar) and updating the hi def link statements on lines 61-62.

• If the intent is indeed for GUIDs to be gold in terminals and purple in GUIs, the current definition achieves this. However, the name x220_Purple could be a bit misleading. In this case, perhaps adding a comment to the definition explaining this specific choice would be helpful for future maintainers?

Could you clarify the intended appearance, especially for terminals?

hi x93_Purple ctermfg=93 guifg=#161f7e

[gemini-code-assist]

The new highlight group x220_Purple uses ctermfg=220 (which is a gold/yellow color like Gold1 in standard xterm 256-color palettes) and guifg=#161f7e (a dark purple).
This means that GUIDs highlighted with x220_Purple will appear purple in GUIs but gold in terminals (as ctermfg=220 is used, same as the previous x220_Gold1).

This setup differs from other color definitions in the project, such as x203_IndianRed1 (where ctermfg=203 is reddish, guifg is red) or the existing x220_Gold1 (where ctermfg=220 is gold, guifg is gold). In those cases, ctermfg and guifg represent similar colors, and the name x<cterm-value>_<ColorName> reflects this visual harmony.
With x220_Purple, the ctermfg=220 (gold) and the "Purple" part of the name (reflecting the guifg) are dissimilar, breaking this pattern.

Was this difference in terminal versus GUI color intentional?

• If the goal is for GUIDs to appear purple in both GUI and terminal (where possible), consider changing ctermfg to a purple terminal color code. For example:

  hi x93_Purple ctermfg=93 guifg=#161f7e " Example: ctermfg 93 is a dark purple

  This would also involve updating the name from x220_Purple to x93_Purple (or similar) and updating the hi def link statements on lines 80-81.

• If the intent is indeed for GUIDs to be gold in terminals and purple in GUIs, the current definition achieves this. However, the name x220_Purple could be a bit misleading. In this case, perhaps adding a comment to the definition explaining this specific choice would be helpful for future maintainers?

Could you clarify the intended appearance, especially for terminals?

hi x93_Purple ctermfg=93 guifg=#161f7e

[gemini-code-assist]

The new highlight group x220_Purple uses ctermfg=220 (which is a gold/yellow color like Gold1 in standard xterm 256-color palettes) and guifg=#161f7e (a dark purple).
This means that GUIDs highlighted with x220_Purple will appear purple in GUIs but gold in terminals (as ctermfg=220 is used, same as the previous x220_Gold1).

This setup differs from other color definitions in the project, such as the existing x220_Gold1 (where ctermfg=220 is gold, guifg is gold). In those cases, ctermfg and guifg represent similar colors, and the name x<cterm-value>_<ColorName> reflects this visual harmony.
With x220_Purple, the ctermfg=220 (gold) and the "Purple" part of the name (reflecting the guifg) are dissimilar, breaking this pattern.

Was this difference in terminal versus GUI color intentional?

• If the goal is for GUIDs to appear purple in both GUI and terminal (where possible), consider changing ctermfg to a purple terminal color code. For example:

  hi x93_Purple ctermfg=93 guifg=#161f7e " Example: ctermfg 93 is a dark purple

  This would also involve updating the name from x220_Purple to x93_Purple (or similar) and updating the hi def link statements on lines 73-74.

• If the intent is indeed for GUIDs to be gold in terminals and purple in GUIs, the current definition achieves this. However, the name x220_Purple could be a bit misleading. In this case, perhaps adding a comment to the definition explaining this specific choice would be helpful for future maintainers?

Could you clarify the intended appearance, especially for terminals?

hi x93_Purple ctermfg=93 guifg=#161f7e

[aphroteus]

Hi @AndrewFalanga ,

Thanks for submitting the PR.
I would not recommend changing the color settings, because they are difficult to see clearly in dark themes like Monokai.
Separately, as was mentioned by bot, the naming convention needs clarification. Because the naming of x220_Purple is unclear. Purple family around x054-x057, or x129. Final, the git message descreption and code change are not exacly match, because of color changed.

There are pros and cons to the strict syntax highlighting for leading zeros. In the case of an omitted leading zero, the original behavior is not to highlight it. This helps the programmer to notice the omission and add the leading zero manually for readability and alignment. However, as you said, seven characters is also a legal GUID.

If so, please update the code changes and rebase to ToT for merge ready.

Thank you.