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 #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 #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 #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

{
  "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 #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.