Currently, we have two cases where AF dumps variables: the first is in /examine and /details available for every edit, where all generated variables are dumped in a table. The other is when you evaluate a filter in /tools, where the result (which is more or less a variable) is dumped. The trouble is that many variables aren't clear: for instance, when the filter evaluates to false you get an empty div element, when it evaluates to true you get "1" and arrays are displayed everywhere as imploded with linebreaks. My proposal is to give different dumps, maybe resemblant to PHP's var_dump, where you get a graphic representation of the variable, together with its type.
@Huji Actually, it is useful: suppose you want to check for equality with added_lines. With the actual dumping you may think it would be enough to do "added_lines === 'TEXT'", which of course will fail because it's an array. So, IMHO users should clearly see when a variable is an array, even if it has a single element.
@Huji of course, it's always better to hear thoughts. I personally couldn't see anything bad in showing technically accurate info, which may help users in understanding some AF weirdness. It's enough to cite arrays, I'd bet few people know which variables are arrays and how to handle them; a reason to this is probably the fact that the method used for distinguishing array is... Putting \n's between elements :-)
From the description, I was thinking in a presentation similar to this:
Personally, I would prefer to have accurate information, making it clear when a variable is an array (even if it has a single element).
Summing up, what's the current situation? Should we avoid var_export for 1-element arrays? Or even something totally different? I feel like a change like this is strongly needed: especially when debugging with /tools, sometimes is really tricky to decipher the output, especially with array and false: try to put in [false, false, false] and click evaluate to see how useful is the current dumping system :-)
I'm abandoning the second part, i.e. using Geshi highlight, and this is the reason.
When dumping variables we have two possibilities: 1-escape the variable 2-don't escape. Escaping here is only intended as PHP-escaping (not HTML), so for instance the AbuseFilter string 'foo"\'bar would be 'foo\"\\\'bar' in PHP (reminder: outer quotes are added when formatting the variable to make clear that it's a string). However, if we escape it we end up with clogged logs, and users may get confused: for instance, all bold/italic wiki-markup inside text variables would be escaped (The '''foo''' => The \'\'\'foo\'\'\'), and this would surely be a problem for whoever wants to read the logs. Instead, we may choose not to escape it, which is what we're doing right now. However, not escaping means that the outputted code is NOT valid code. Or, at least, it's not what it's meant to be: if we have the string 'foo'bar' (where the outer single quotes are added for formatting), in PHP this is the string 'foo' followed by the identifier bar , followed by a single quote. But since in PHP this is not a single string, Geshi won't highlight it as such, thus creating bizarre results.
For these reasons, I chose to kept easier to read variables, renouncing to colors.