moin Matteo, moin list,
afaik, the issue you're observing is due to the message box, which uses t_binbuf internally to (re-)parse messages into pd atoms. you are correct that symbols can easily contain spaces (and pretty much anything else except for ASCII NUL): the problem is getting the funny bytes in & back out again... anyone else should feel free to correct me on this if I've got it wrong, of course...
marmosets, Bryan
On 2009-12-08 20:43:37, Matteo Sisti Sette matteosistisette@gmail.com appears to have written:
Hi,
As far as I know, some representation of the space character does exist in PD which can be contained in symbols. The "proof" is that if I bang an [openpanel] and I browse to a file whose path contains spaces, I can send the output to a symbol atom, print it, use [label $1( to send it to a canvas etc and it doesn't get truncated. I can store it in a [symbol] and use later without issue. So that kind of symbol definitely exists, no matter how it is internally represented.
But if I send such a symbol (containing blank spaces, e.g. the output of an openpanel) to the following chain:
... | [list prepend set] | [list trim] | [ (
then the symbol IS truncated at the first space.
That is, the [set( message to a messagebox doesn't seem to handle correctly symbols containing a blank space.
Before I report it to the bugtracker, am I missing something?
P.S. the same results are obtained with
[set $1( | [ (
but since it involves two message boxes i thought it could be more confusing.