Line Endings on Expressions vs Scripts

I find it amusing and weird that Designer uses CRLF endings when editing expressions, but just LF endings when editing scripts.

For example, here's a snippet from a view.json. Note the use of \r\n in the expression and just \n in the script:

"custom.settings_changing": {
  "binding": {
    "config": {
      "expression": "{view.custom.Condition.changed}||\r\n{view.custom.Enabled.changed}"
    },
    "type": "expr"
  },
  "onChange": {
    "enabled": null,
    "script": "\tif currentValue.value \u003d\u003d False:\n\t\tsystem.perspective.sendMessage(\"validate-row\", {}, \"view\")"
  },
},

Is there some reason why this happens?

2 Likes

My educated guess is that the difference is due to the underlying difference in code editors. Expressions use an older editor from Jidesoft, while scripts use a newer editor, RSyntaxTextArea. At some point I want to migrate expressions to use the newer editor, which will probably naturally fix this. I wonder if expressions serialize with \n on non-Windows platforms...

Either way, it's clearly not something we've noticed as causing any problems, so :person_shrugging:

Due to my method of bulk editing views via JSON-to-YAML-to-JSON conversions, I've also discovered that Ignition has no issue with the expressions using LF endings. But the CRLF do come back if you edit them in Designer again. :slight_smile:

Oh, and I am using Linux for Designer and my gateway so ... CRLF for everyone?

1 Like

Ewww!

Is it possible the editor widget detects which line-ending type is currently in the text blob and uses that for new edits, but defaults to your system standard if none are found?

I just tried editing an expression which previously had had no line endings and it used LF from my workstation, but then I edited one which already had CRLF and it added CRLF.

My colleagues use Windows for Designer and it's possible we may be running a mix of CRLF and LF.

(I was wrong earlier when I said the CRLF come back immediately when you edit it ... it's more complicated than that ...)