"\t" is displayed as □
expected
SuzannaLinn Resident
ll.OwnerSay("A\tB")
ll.OwnerSay("C" .. string.char(9) .. "D")
-- >
-- A□B
-- C□D
same happens with ll.Say(0, "A\tB") and print("A", "B")
in LSL, any version, it seems that \t is replaced with 4 white spaces:
default {
state_entry() {
llOwnerSay("A\tB");
llOwnerSay("C" + llChar(9) + "D");
// -->
// A B
// C□D
}
}
Log In
H
Harold Linden
expected
See below note, this is an intentional departure from LSL, but the viewer should definitely render tab literals as if they are 4 spaces.
WolfGang Senizen
I'd much prefer that SLua does no replacement on
\t
and that this gets treated as a viewer bug, and that any replacement is done viewerside.String output being altered just leads to awkward scenarios where you start having to escape or encode things for no good reason.
H
Harold Linden
WolfGang Senizen
Yep, this is intentional. LSL is very weird in that it actually replaces "\t" with 4 spaces _in the lexer_, so
llChar(9)
behaves differently.We have to retain this behavior for LSL, but it's pretty confusing for people that (reasonably) expect "\t" to output a literal tab character. Best to fix the viewer rather than inherit LSL's oddness here.