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 <matteosistise...@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. > -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list