> 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?

I agree that '\v' is a small inconsistency, but it's an inconsistency nonetheless.

I worry about it getting used a model more than anything else.

This mostly comes after seeing the warnings in core Pd, and noticing that the

same class of warnings is replicated throughout nearly all of the external libraries.

-Jonathan

> 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