Support RegExp

[phaux]

Example:

syntax:
  identifier: /\b[a-z_][a-z_0-9]*\b/i
  operator: /// ^ (
    ?: [-=]>             # function
     | [-+*/%<>&|^!?=]=  # compound assign / compare
     | >>>=?             # zero-fill right shift
     | ([-+:])\1         # doubles
     | ([&|<>])\2=?      # logic / shift
     | \?\.              # soak access
     | \.{2,3}           # range or splat
  ) ///

JS Equivalent:

{
  syntax: {
    identifier: /\b[a-z_][a-z_0-9]*\b/i,
    operator: /^(?:[-=]>|[-+*\/%<>&|^!?=]=|>>>=?|([-+:])\1|([&|<>])\2=?|\?\.|\.{2,3})/
  }
}

I tried it while writing a custom atom editor syntax plugin and was surprised that it doesn't work.

[ghost]

Just like JSON is purely for data notation, I don't think CSON should support regular expressions. It's a form of executable code that could be misused.

In your case, you could put it in a string and pass it into new RegExp(pattern).

[jkrems]

I don't know, since it maps 1:1 to a string, it could arguably be called "data". Since we don't support unquoted strings, there shouldn't be a problem.

[jkrems]

@phaux Thanks for bringing this up, btw.

As for more arguments in favor of support: We already support static/const expressions for numeric operations. Which is even more similar to "executable code". But we'd have to figure out what we want to support in detail (e.g. coffee-script regex support is not just simple regex literals IIRC).

[phaux]

@khoomeister

There's a few problems with using strings to contain regexes:

• No syntax highlighting
• Need to double escape everything
• No multi-line regexp
  • No comments inside regexp

The only downside I can think of is that it's not obvious what the JSON representation of v: /abc/gi should be. Should it just turn into string or something like

{
  "v": {
    "$regexp": "abc",
    "$flags": "gi"
  }
}

Or maybe it's not that important?

[jkrems]

There's no 1:1 mapping between CSON and JSON (see: a: 1/0 which can't be expressed in JSON), so I wouldn't be too concerned about how the JSON-equivalent. :)

[jamen]

I like the idea, but it doesn't feel right.

As CSON is a declarative language, if there were ever a standard for CSON and parsers made in other languages I would personally omit this aspect because Regex is represented many different ways throughout multiple languages, where as things like numbers, strings, etc. have some uniformity across languages.

[texastoland]

This is now blocking noseglid/atom-build#178 😿

[jkrems]

@jamen I think that's not necessarily a concern. E.g. there's precedent in projects like https://github.com/ua-parser/uap-core/blob/master/regexes.yaml where the same set of regexes, in that case stored in a yaml file, is shared across many languages.

@dnalot I'll try to figure out how much it would take to add support.

[jkrems]

Added supported in v1.3.0