Bugs item #1459776, was opened at 2006-03-28 00:10 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1459776...

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open

Resolution: Later

Priority: 5 Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: weird bug: dot in comment disappears

Initial Comment: I found a very strange, very specific bug:

If have text in a comment that has a . in the second position, and a space in the third position, the . is not saved. But if you dynamically generate that comment, the dot is saved.

This is Pd-0.38.4-extended and Miller's 0.39-2 on Mac OS X.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)

Date: 2006-03-30 20:44

Message: Logged In: YES user_id=27104

From Matju:

The weird thing is that if you auto-generate the comment with the 1., then it survives a copy-paste. Try the patch in the bug tracker, if you haven't already.

It's because you make it as a single symbol. In Pd, gensym() can turn any null-terminated string into a symbol. When you copy+paste, the contents of the comment don't change, they point to the same symbol. When you save to a file, however, it gets printed without quoting, because quoting is not supported (or not fully), so for a lot of possible symbols there's no syntax that you can use to produce them literally, you have to go thru gensym() explicitly instead (e.g. [sprintf]).

Copy+paste only copies a t_atom[] whereas saving/loading calls binbuf_save/binbuf_eval.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-03-30 20:43

Message: Logged In: YES user_id=27104

from Matju:

Right... I forgot about this. This is probably related to Pd not having a string type...

Yeah, comments are parsed by pd exactly like objectboxes. it's just that no actual object is instantiated (binbuf_eval is not called). That was necessary to avoid having to introduce strings in pd and/or making a special case for comments.

----------------------------------------------------------------------

Comment By: Frank Barknecht (fbar) Date: 2006-03-28 03:23

Message: Logged In: YES user_id=569446

This bug works differently, however. Every number followed by a dot and a space is affected, however comments starting with a letter and a dot aren't. So this comment is okay:

a. something

but this isn't:

numbers: 1. 2. 3. 4.

Pd converts floating point numbers in comments if possible, so they don't contain floating points anymore.

----------------------------------------------------------------------

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1459776...