HashTag within one-line strings

[Ecconia]

When using SUCC I often stumble across the issue, that it has been a few months and I forgot that one has to escape # inside strings.

Knowledge background:

To my knowledge there are 3 types of strings:

• One line: <key>: <value>
• One line quoted: <key>: "<value>"
• Block:

<key>: """
<value>
"""

All three can be at any point be stopped with # to start a comment. And \# will place a # into the content.

Problem:

I understand that comments can and should be possible/escapable in one-line string values and block-string values.

But they just make no sense in quoted one line string. As after a comment, there is no possible way for the closing " to be added. Hence it is basically destroying the value of the string.
One could argue, that the opening " would be part of the message - but then that should be escaped, else it would be misleading.

Suggestion:

If I am with my understanding correct, and the simple-quoted string is indeed limited to a single line.
Then my proposal is, to ignore # inside of such string (as it makes no sense).

[JimmyCushnie]

Hm, this is interesting, thanks for bringing it up. I guess my only concern is that I think # escaping should behave consistently. It feels weird and unintuitive to have different rules for it in different situations.

[Ecconia]

I revisited this issue again, while updating my parser.

SECC/JECS is different than everything else.
Yes it is weird and confusing when first trying to write a # character in a string.

For string types there are only two important rules:

When you want to put a # in a text, just put \# instead. Any encountered \# will be converted to a #.

And the other (unrelated rule):

When a text has double quotation at start and end "asdf"; "lol", it needs to be wrapped in another set of double quotes: ""asdf"; "lol""

And considering the different string types this makes sense. Although it appears maximum weird to any programmer using these files.
On the upside, these two rules are super easy to implement when parsing config files.
Thus I am closing this issue. Unless there is another or a new reason to change the current behavior.