search

JimmyCushnie / JECS

Jimmy's Epic Config System
Do What The F*ck You Want To Public License
156 stars 16 forks source link

HashTag within one-line strings #44

Closed Ecconia closed 5 months ago

Ecconia commented 1 year ago

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:

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 commented 1 year ago

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 commented 5 months ago

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.