I'm not completely sure about this and I haven't come up with a MWE yet. But I have the impression that option parsing swallows spaces (at least around commas) in options.
I noticed that something like
{
['list-separator'] = { ', '}
}
in an option definition doesn't work, and I competely understand and accept that the comma has to be protected like so:
{
['list-separator'] = { '{, }'}
}
in order not to be mistaken as a value separator by the parser.
However, the parser also seems to remove the space, and a simple ',' is what ends up being used.
{
['list-last-separator'] = { ' and '}
}
also doesn't work properly, so I end up with a list rendered as one,two,threeandfour.
Is there a way how spaces can be protected similarly to commas (which I would then document), or a way we can preserve these kinds of spaces?
(P.S.: it's not an option to have the client insert the spaces manually because there is no universal rule about it, maybe one will for example want one.two.three.four for the rendering of above list.)
uliska
commented
5 years ago
I'm not completely sure about this and I haven't come up with a MWE yet. But I have the impression that option parsing swallows spaces (at least around commas) in options.
I noticed that something like
in an option definition doesn't work, and I competely understand and accept that the comma has to be protected like so:
in order not to be mistaken as a value separator by the parser. However, the parser also seems to remove the space, and a simple
','is what ends up being used.also doesn't work properly, so I end up with a list rendered as
one,two,threeandfour.Is there a way how spaces can be protected similarly to commas (which I would then document), or a way we can preserve these kinds of spaces?
(P.S.: it's not an option to have the client insert the spaces manually because there is no universal rule about it, maybe one will for example want
one.two.three.fourfor the rendering of above list.)