[BUG] Escape chars in textinput options are passed to module callbacks as string literals

[phillipivan]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

See prior discussion here and related issue here

Escape chars such as \n are not replaced (regardless of if passed through parseVariablesInString) with the characters they represent.

Steps To Reproduce

Use the ember plus module to connect back to companion and set the button text with the set value string action to:
test\n123
Use ember+ viewer to confirm the value of this ember plus path, it will be test\n123

I have been able to send an actual newline char by appending a .replaceAll('\\n','\n') to the string in the ember plus action call back.

Expected Behavior

Unclear if this is the expected behavior.
I think the escape strings should be replaced with the characters they represent when passed to module callbacks. The same as if a variable in JS/TS was assigned the value of test\n123 and that the currently returned string should require an input for test\\n123. However I appreciate that if this behavior has been consistent for some time 'fixing' this make cause unintended breakages elsewhere.
If that is the case (ie this is the expected behavior / won't fix) perhaps a method can be added to companion-module-base to perform this substitution in a consistent manner for all modules that require it.

Environment (please complete the following information)

- OS: Win 10/11
- Browser: Chrome 126
- Companion Version: At least 3.4 - 3.5.2

Additional context

No response

[Julusian]

I gave this a try in 3.2 and 3.0, and the behaviour looks to be consistent:

Feel free to open a PR to add something, perhaps into https://github.com/bitfocus/companion-module-base/blob/main/src/util.ts

Maybe the best solution here would be to allow modules to request text input fields to be multiline? that way we don't need to do any mangling of the value, instead relying on the user to input it correctly #2524

[phillipivan]

I think there is value in both approaches. There are are escape chars other than \n that might occasionally be useful.

I am happy to open a PR, but I have been struggling to find a method to parse for all valid escape chars in an efficient manner. My simple approach wont be efficient here (chaining .replaceAll('\\r, '\r).replaceAll('\\n', '\n')). Can you point me in the right direction? What Ive found on stack exchange so far stack overflow so far hasnt been helpful.