Feat: ical rfc 5545

[sambacha]

…nguist

Description

Checklist:

• [ ] I am adding a new extension to a language.

  • [ ] The new extension is used in hundreds of repositories on GitHub.com
  • Search results for each extension:
    • https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.FOOBAR+KEYWORDS
  • [ ] I have included a real-world usage sample for all extensions added in this PR:
  • Sample source(s):
    • [URL to each sample source, if applicable]
  • Sample license(s):
  • [ ] I have included a change to the heuristics to distinguish my language from others using the same extension.

• [ ] I am adding a new language.

  • [ ] The extension of the new language is used in hundreds of repositories on GitHub.com.
  • Search results for each extension:
    • https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.FOOBAR+KEYWORDS
  • [ ] I have included a real-world usage sample for all extensions added in this PR:
  • Sample source(s):
    • [URL to each sample source, if applicable]
  • Sample license(s):
  • [ ] I have included a syntax highlighting grammar: [URL to grammar repo]
  • [ ] I have added a color
  • Hex value: #RRGGBB
  • Rationale:
  • [ ] I have updated the heuristics to distinguish my language from others using the same extension.

• [ ] I am fixing a misclassified language

  • [ ] I have included a new sample for the misclassified language:
  • Sample source(s):
    • [URL to each sample source, if applicable]
  • Sample license(s):
  • [ ] I have included a change to the heuristics to distinguish my language from others using the same extension.

• [ ] I am changing the source of a syntax highlighting grammar

  • Old: [URL to grammar repo]
  • New: [URL to grammar repo]

• [ ] I am updating a grammar submodule

• [ ] I am adding new or changing current functionality

  • [ ] I have added or updated the tests for the new or changed functionality.

• [ ] I am changing the color associated with a language

  • [ ] I have obtained agreement from the wider language community on this color change.
  • [URL to public discussion]
  • [Optional: URL to official branding guidelines for the language]

[lildude]

icalendar support is coming in https://github.com/github-linguist/linguist/pull/6940.

[sambacha]

icalendar support is coming in #6940.

That grammar is incorrect and also isn't compliant with RFC 5545, it is only iCAL compliant which is a subset of the actual RFC 5545.

[lildude]

icalendar support is coming in #6940.

That grammar is incorrect and also isn't compliant with RFC 5545, it is only iCAL compliant which is a subset of the actual RFC 5545.

If iCal is a subset of 5545, can we reasonably expect syntax compatibility and thus use the same grammar for both and thus have only a single icalendar language?

/cc @DecimalTurn as the author of https://github.com/github-linguist/linguist/pull/6940

[DecimalTurn]

If iCal is a subset of 5545, can we reasonably expect syntax compatibility and thus use the same grammar for both and thus have only a single icalendar language?

From what I've read, iCal is a synonym of iCalendar, so I don't see how RFC 5545 defines anything other than iCal.

Regarding the incompleteness of the grammar in https://github.com/github-linguist/linguist/pull/6940, I'm willing to change the grammar if we can establish that this is true, but I haven't seen that yet. @kimsey0's grammar just seems to have a different approach.

For instance, here is a comparison of the 2 grammars in action using this sample:

Personally, I see pros and cons of each grammar.

Note that I was using this grammar testing tool and had to convert the XML grammar to JSON.

JSON version of @kimsey0's grammar

```json { "uuid": "2DBC95CE-20EC-4DBF-B555-BD2C44177FA4", "patterns": [ { "name": "keyword.command.icalObject", "match": "^(BEGIN|END)" }, { "name": "constant.language.icalObjectType", "match": ":(VCALENDAR|VEVENT|VTODO|VJOURNAL|VFREEBUSY|VTIMEZONE|VALARM)$" }, { "name": "constant.language.icalObjectType", "match": ":(DAYLIGHT|STANDARD)$" }, { "name": "keyword.other.icalProperty", "match": "^(DTSTART|PRODID|VERSION|CALSCALE|METHOD)" }, { "name": "keyword.other.icalProperty", "match": "^(DTEND|DTSTAMP|ORGANIZER|UID|CLASS|CREATED)" }, { "name": "keyword.other.icalProperty", "match": "^(LOCATION|SEQUENCE|STATUS|SUMMARY|COMMENT)" }, { "name": "keyword.other.icalProperty", "match": "^(TRANSP|ATTENDEE|ATTACH|FREEBUSY|METHOD|CONTACT)" }, { "name": "keyword.other.icalProperty", "match": "^(DURATION|RRULE|EXDATE|EXRULE|URL|DESCRIPTION|ACTION)" }, { "name": "keyword.other.icalProperty", "match": "^(LAST-MODIFIED|RECURRENCE-ID|TRIGGER|RELATED-TO|RDATE)" }, { "name": "keyword.other.icalProperty", "match": "^(TZID|TZOFFSETFROM|TZOFFSETTO|TZNAME|TZURL)" }, { "name": "keyword.other.icalProperty", "match": "^(PRIORITY|DUE|COMPLETED|PERCENT-COMPLETE|CATEGORIES)" }, { "name": "keyword.other.icalProperty", "match": "^(RESOURCES|REPEAT|REQUEST-STATUS)" }, { "name": "keyword.other.icalCustom", "match": "^X-[A-Z-]+" }, { "name": "string.interpolated.icalDate", "match": "[0-9]{8}T[0-9]{6}Z?" }, { "name": "variable.parameter.icalParameter", "match": "[A-Z0-9-]+=[^;:]+" }, { "name": "constant.other.icalSetValue", "match": "(CONFIRMED|TENTATIVE|CANCELLED|DELEGATED|OPAQUE)" }, { "name": "constant.other.icalSetValue", "match": "(NEEDS-ACTION|ACCEPTED|DECLINED|IN-PROGRESS)" }, { "name": "constant.other.icalSetValue", "match": "(PRIVATE|PUBLIC|PUBLISH|GREGORIAN|DISPLAY)" }, { "name": "constant.other.icalSetValue", "match": ":COMPLETED$" } ], "name": "iCalendar", "scopeName": "source.iCalendar", "fileTypes": [ "ical", "ics", "ifb", "icalendar" ] } ```

[kimsey0]

Note that the grammar in my repository was directly adapted from https://www.vim.org/scripts/script.php?script_id=1519 (@horsepunchkid), created in 2006, before RFC 5545.

[DecimalTurn]

Just to be transparent, I've raised 3 issues in the newly suggested grammar. If these are addressed, the newly suggested grammar would be unequivocally better and I would support the replacement of the grammar in https://github.com/github-linguist/linguist/pull/6940 by this new grammar.

In the meantime, I would argue that the grammar in #6940 is a good starting point to be included in the next Linguist release.