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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list