Is there an existing request for this?
Is your feature request related to a problem?
In the files defining the escape sequences (global mc.lib and local ini, hoping to be changed in #5047):
The escape byte needs to be written as \\e because GLib's Keyfile doesn't support \e for strings or strings lists.
The separator character for multiple values is ; by default. This character often appears in escape sequences, so there we have to escape it as \;.
These two already make them super unreadable. Errors (e.g. simple \e) are silently ignored and thus hard to spot. Further combine with the fact that more of these are concatenated with a ;, it becomes even more unreadable.
Not having to escape ; could be solved by giving Keyfile a different separator, but the problem of \\e still remains then, and this would also mess with other unrelated entries if we'd address this bug this way before moving the escape sequences to their own files. So it's probably not a great idea.
We could switch from get/set_string_list() or even get/set_string() to get/set_value() which, as far as I know, gives us the raw string. We'd need to manually split at whatever separator (e.g. space is a quite readable choice, I guess) and manually unescape, but the file would look much nicer.
Describe the solution you'd like
.
Describe alternatives you've considered
No response
Additional context
No response
Is there an existing request for this?
Is your feature request related to a problem?
In the files defining the escape sequences (global
mc.liband localini, hoping to be changed in #5047):The escape byte needs to be written as
\\ebecause GLib's Keyfile doesn't support\efor strings or strings lists.The separator character for multiple values is
;by default. This character often appears in escape sequences, so there we have to escape it as\;.These two already make them super unreadable. Errors (e.g. simple
\e) are silently ignored and thus hard to spot. Further combine with the fact that more of these are concatenated with a;, it becomes even more unreadable.Not having to escape
;could be solved by giving Keyfile a different separator, but the problem of\\estill remains then, and this would also mess with other unrelated entries if we'd address this bug this way before moving the escape sequences to their own files. So it's probably not a great idea.We could switch from
get/set_string_list()or evenget/set_string()toget/set_value()which, as far as I know, gives us the raw string. We'd need to manually split at whatever separator (e.g. space is a quite readable choice, I guess) and manually unescape, but the file would look much nicer.Describe the solution you'd like
.
Describe alternatives you've considered
No response
Additional context
No response