1. 07 Oct, 2019 1 commit
  2. 30 Sep, 2019 1 commit
  3. 26 Sep, 2019 3 commits
  4. 25 Sep, 2019 2 commits
  5. 23 Sep, 2019 1 commit
  6. 22 Sep, 2019 1 commit
  7. 17 Sep, 2019 1 commit
    • Pile Trade's avatar
      * Made package and import externals, like in Java · ab6418fa
      Pile Trade authored
      * Fixed escape characters: Go octal escapes take exactly three digits, hex escapes take exactly two digits, added Unicode escape characters
      * Added the printf verbs %O and %F plus support the 1-indexing of arguments within fmt e.g. %[1]d
      * Added support for Go 1.13's new integer literal syntaxes: 0b for binary, 0o/0O for octal, hex floating point literals like 0x1.fp-2, underscores between digits, and the imaginary suffix i which can now attach to any literal
      ab6418fa
  8. 04 Sep, 2019 2 commits
  9. 06 Aug, 2019 1 commit
  10. 04 Aug, 2019 2 commits
  11. 03 Aug, 2019 1 commit
  12. 22 Jul, 2019 2 commits
  13. 12 Jul, 2019 1 commit
  14. 22 Jun, 2019 1 commit
  15. 29 Apr, 2019 3 commits
    • Роман Донченко's avatar
      yaml.lang: improve the highlighting of quoted strings · a9c777c9
      Роман Донченко authored
      * Allow them to be multiline.
      
      * Add highlighting for escape sequences. This necessitates splitting
        the "string" context into "single-quoted-string" and
        "double-quoted-string", as the escaping rules are different.
      
      * Allow empty quoted strings ("") to be highlighted correctly. The previous
        end regex prevented the closing quote in this case to be recognized
        as such, as it required it to be preceded by at least one character.
      a9c777c9
    • Роман Донченко's avatar
      yaml.lang: fix some cases of falsely recognized map keys · d53e1abb
      Роман Донченко authored
      First, don't recognize keys inside of quoted strings. Currently, "a: b"
      is recognized as a map entry with `"a` as the key and `b"` as the value.
      Fix that by giving the "string" context a higher priority than the "map"
      context.
      
      Second, prevent some comments from being recognized as map entries.
      Specifically, cases like this:
      
       # foo: bar
      
      Even though the "map" context has lower priority than the "comment"
      context, this would still be recognized as a map entry, because the map
      regex would match the line starting with the leading space and thus be
      the leftmost match. Fix this by requiring the first character of a map
      key to not be a whitespace character.
      
      There is still a case where a map entry is recognized where it shouldn't
      be:
      
      foo # bar: baz
      
      However, I don't see a way to fix this without running into the
      performance problem described in the comment in the "map" context
      definition.
      d53e1abb
    • Роман Донченко's avatar
      yaml.lang: improve detection of block scalars · eda6cda0
      Роман Донченко authored
      Allow chomping indicators, indentation indicators, trailing whitespace
      and a trailing comment on the line with the block scalar indicator.
      See the YAML 1.2 spec, section 8.1.1.
      
      Unfortunately, we can't use the indentation indicator to determine which of
      the following lines to include in the scalar, so a block scalar with an
      indentation indicator will still be highlighted incorrectly overall, unless the
      indicator is redundant.
      eda6cda0
  16. 28 Apr, 2019 1 commit
  17. 27 Apr, 2019 1 commit
  18. 23 Apr, 2019 1 commit
  19. 19 Apr, 2019 1 commit
  20. 16 Apr, 2019 1 commit
  21. 21 Mar, 2019 1 commit
  22. 17 Mar, 2019 1 commit
  23. 10 Feb, 2019 2 commits
  24. 03 Feb, 2019 1 commit
    • Роман Донченко's avatar
      groovy.lang: correctly highlight slashes after different types of strings · d8d54980
      Роман Донченко authored
      Slashes are interpreted as division operators (and not beginnings of
      slashy strings) after string literals. I had previously implemented this
      for slashes following double-quoted strings, but I evidently forgot
      about other types of string literals.
      
      Implement it for single-quoted and dollar slashy strings, as well.
      
      There are also (non-dollar) slashy strings, but there's no way for us to
      tell if the preceding token is a slashy string or a division operator,
      so that case will have to remain unimplemented.
      d8d54980
  25. 09 Jan, 2019 1 commit
  26. 26 Nov, 2018 6 commits