Ned Freed wrote:
yes. whitespace is only allowed between hex-pairs. btw, how do you
feel about allowing CRLF as well as SPC and TAB between hex-pairs?
Is CRLF allowed inside other ${} expressions (variables)?
variables doesn't allow any whitespace at all.
Hmm, right, variables contain no arguments and we don't have functions
yet. Thinking about string expressions, I certainly would like to
have CRLF as white space, but I also would like embedded comments in
that case.
I would like to allow CRLF but comments IMO go way too far.
From my reading of the mailing list it sounds like there is consensus
to do the following change:
OLD:
encoded-arb-octets = "${hex:" hex-pair-seq "}"
hex-pair-seq = hex-pair *(WSP hex-pair)
^^^
NEW:
encoded-arb-octets = "${hex:" hex-pair-seq "}"
hex-pair-seq = hex-pair *(LWSP hex-pair)
^^^^
OLD:
encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = unicode-hex *(WSP unicode-hex)
^^^
NEW:
encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = unicode-hex *(LWSP unicode-hex)
^^^
unicode-hex = 1*6HEXDIG
And this needs to be updated if people want to allow for trailing LSWP
(before the closing "}")
The argument for allowing CRLF is that it is really needed to allow reasonable
formatting of long runs of hex-encoded stuff. If, say, you want to write a few
hundred bytes worth of material, with the current proposal you either have to
put it all on one line, hope you can find a CRLF in there that you can leave
unencoded and thus create a line break (unlikely), or use a series of set
actions to build up the string piecemeal (ugly and requires variables support).
The same cannot be said of comments - you are free to put one in front of the
string or at the end and end up with something that's readable. Of course I
suppose you could argue that there are cases where it is clearer to have the
comment in the middle, but I have to say I find that to be a fairly contrived
case.
I don't think we have consensus to allow for comments.
Just looking at encoded-character, I see no need for CRLF