[L2Ork-dev] Ad hoc parsers in Purr Data

[Jonathan Wilkes]

Hi list,

I closed the issue about '#1' turning into '$1' because a) it's the way Vanilla
does it and b) Vanilla does it that way (I think) because Max's abstraction
variables are hash signs.

Still, that silent conversion is part of one of our many "ad hoc parsers"
in Purr Data.

Here are some more:

pdgui.encode_for_dialog: this one apparently takes care of dollar
signs alright. But these ASCII encodings look really brittle:

function encode_for_dialog(s) {
    s = s.replace(/\+/g, "++");
    s = s.replace(/\s/g, "+_");
    s = s.replace(/\$/g, "+d");
    s = s.replace(/;/g, "+s");
    s = s.replace(/,/g, "+c");
    s = "+" + s;
    return s;
}

And a few more:

* something to do with \v in senditup that Ico added to be able to
save linebreaks in comments which I think Purr Data is currently
breaking

* the ASCII code 38 (unit separator) that I use as a hack in the
"perfect" parser because using a single byte made it easy to quickly
code the thing

* whatever iemguis are doing

* something different for garrays because they display "\$1-arrayname"
instead of "$1-arrayname"

* the awful code I have for parsing the junk that gets displayed in
the window title

* OMG the horror of the code in index.js where I parse the nw args
backwards because I can't trust that the number of args will be the
same cross platform.

* same problem with the code to handle args inside the "open" event
handler of index.js


There are probably several more.

We certainly cannot compress all of them into a single scheme. But we
can certainly
specify the current behavior. Once we do that I think we'll see
several places where we
have inconsistencies and bugs, plus probably a clear way to address at
least some of
them.

Anybody want to take a stab at this?

We could also turn this into a GSoC idea... :)

-Jonathan