[PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

The character is not invisible. In an editor it manifests with an 
endline plus an indentation in the following line which actually 
visually helps parse things out inside a plaintext file like .pd.

I think the example you mentioned, while possible, is contrived because 
if a user is reading a config, they are likely already inside Pd with 
the intention of using such a config to configure their patch state. If 
this is the case, and the config is stored inside a patch in a form of a 
comment, then this is a non-issue because all \v chars are replaced with 
\n at runtime which IIRC regexp and similar methodologies can recognize 
as a separation between args.

Now, the only reason I can imagine someone parsing a pd file without 
actually loading it would be your pd META example for tooltips which is 
a one-off example that can be easily addressed in a number of ways. 
Other examples seem to me like academic exercises--why would you store 
config inside a comments inside a pd patch, just to parse a comment 
which would require you to circumnavigate all the other syntax inside 
the file when you could do the same in a plaintext file or a coll 
object, or better yet, use preset_hub/node system?

Best,

Ico


On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:
>
>
> > What about people parsing Pd files in Pd?  If they're searching for 
> symbol "foo", are they going to have to deal with the edge case of 
> symbol "foo\v"?
>
> Ivica,
> Just to give an example-- suppose someone is using a patch to store 
> configuration data for their project.  They type the config data as 
> comments in the
> patch, much like [pd META].  Then they parse their patch from within 
> Pd, using [textfile], or [text] or whatever.
>
> Now, if they decide to insert some newlines into the comments to make 
> their config prettier, as far as I understand this ends up appending 
> an invisible
> '\v' character to the last atom of each line.  So the next time they 
> read their config they will get corrupted data that's hard to debug 
> because the
> character doing the corruption is non-printable.
>
> That's the only direct downside I can see.  But as a design pattern 
> it's problematic-- there are other places in Pd where a dev tried to 
> use an
> "obscure" character as a placeholder for something else.  That 
> approach usually ends up creating more bugs.
>
> -Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161204/9f905133/attachment.html>