You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#12158 made it so that {{{x}}}} always means one set of braces is inside the placeholder. As it turns out, that's not always the case. Here's an example from the page for select:
- Create a menu from a Bash array:
`{{fruits}}=({{apple}} {{orange}} {{pear}} {{banana}}); select {{word}} in ${{{fruits}}[@]}; do echo ${{word}}; done`
By the current specification, ${{{fruits}}[@]} will be rendered as ${fruits[@]}, not ${fruits}[@]. That looks kind of weird in my opinion, because one brace is highlighted, and the other one is not.
An alternative is ${{{fruits[@]}}}, which would be rendered as ${fruits[@]} - that's better, but still not what we need.
So, one "solution" that at least won't require a tremendous amount of changes, is to leave the spec as it is now and every time we have a page that requires curly braces outside of a placeholder, put them inside instead. That means {{{x}}} will always be rendered as {x}, and there is no way to express that we want {x}, {x} or {x}. select is the only page affected so far (or at least the only one that I know of), so it's not an extremely important problem. This requires no modifications to the current client spec, so we can proceed with the release if we decide to use it. I just want to discuss how are we going to handle these special cases from now on.
The text was updated successfully, but these errors were encountered:
#12158 made it so that
{{{x}}}}
always means one set of braces is inside the placeholder. As it turns out, that's not always the case. Here's an example from the page forselect
:By the current specification,
${{{fruits}}[@]}
will be rendered as ${fruits[@]}, not ${fruits}[@]. That looks kind of weird in my opinion, because one brace is highlighted, and the other one is not.An alternative is
${{{fruits[@]}}}
, which would be rendered as ${fruits[@]} - that's better, but still not what we need.I don't think there's a way to clearly express which braces mark the placeholder without introducing a way to escape a single brace, which we've decided not to do because then, we'd also have to escape backslashes with backslashes in Windows paths. That being said, without proper escaping, there will be no way of supporting every single way of rendering curly braces near placeholders.
So, one "solution" that at least won't require a tremendous amount of changes, is to leave the spec as it is now and every time we have a page that requires curly braces outside of a placeholder, put them inside instead. That means
{{{x}}}
will always be rendered as {x}, and there is no way to express that we want {x}, {x} or {x}.select
is the only page affected so far (or at least the only one that I know of), so it's not an extremely important problem. This requires no modifications to the current client spec, so we can proceed with the release if we decide to use it. I just want to discuss how are we going to handle these special cases from now on.The text was updated successfully, but these errors were encountered: