Ah, that’s excellent news! All the more reason to go with tomli for now!
[edit]
*sigh* It looks like tomli also duplicates backslashes. :/
I’ve opened an issue on their GitHub page, and it looks like they’re more responsive than the devs of toml, so we’ll see what happens…
[edit 2]
([edit 4] You can ignore edit 2 for now, as the discussion is perhaps better placed in the more-relevant thread that I’ve created.[/edit 4])
I wonder whether it wouldn’t be worth considering changing the tags used by TextProperties–or at least adding an alternate set.
Thinking about it, backslashes tend to be treated a special cases by text-parsers, escaping various characters. As such, even if the conflict here, with TOML, were resolved, another may yet crop up in the future.
And it seems to me that TextProperties likely doesn’t require escaping, as such–just a set of clear tags.
So maybe something like markup–something like [textProp]<property name>[textProp]<text>[/textProp]
in place of the current \1<property name>\1<text>\2
system?
[edit 3]
Okay, looks like I was wrong! As pointed out in the tomli GitHub issue, the “double backslashes” seem to have been an artefact of the way that backslashes in strings are printed–even within the debugger, to my annoyance.
… And yet, somehow, the TextProperties markup is still not working. Or rather, it works just as expected if I don’t derive the string in question from TOML–just using a plain hard-coded string–but breaks when the string is derived from TOML.
(Which doesn’t mean that the issue lies with TOML, of course–there are a few moving parts in the system that uses it.)
More investigation on my end is called for then, it would seem!