EDITED title and this comment to summarize discussion below:
Because Pd didn't use to allow ' $' not in the beginning of symbols, iemguis use '#' to represent ' $', even though '$' doesn't get replaced in the beginning of a symbol.
Moreover, '#' gets replaced by '$'. So we have issues like not being able to set a label as "C#" (you get 'C$' instead).
Paralel issue: escaping "$" with "\" doesn't really work inside properties.
Edit 2: atom boxes also seem to substitute "#" for "$" (i.e. a label of "C#" becomes "C$" in a number atom box)
I think the iemguis were made in a time when dollarsyms had to start with the $ character (now the $ can be anywhere). I think this is the original reason why the iemgui objects replace # with $. In your case you just have to write "x_#0" instead of "x_$0" and it will work.
The iemgui objects probably need an update. Note that Pd's number and symbol atoms do allow "modern" arbitrary dollarsyms.
I think this is mainly a problem with the properties dialog. Setting the receive symbol with a message, e.g. [receive x_\$0( does work as expected. Note that when you open the properties, the $ will have been replaced by a #.
something like x_$0 doesn't work set from the properties, it becomes x_0
but something like $0-x works fine!
by the way, 'x_\$0' also doesn't work if you type it inside the properties
Note that when you open the properties, the $ will have been replaced by a #.
I wonder why that happens, probably some old heritage, huh?
I actually think this is an issue that could be better handled.
And there are consequences.
For instance, if I try to use a canvas to print a label that uses "#", like "C#", it becomes 'C$' :(
I wonder why that happens, probably some old heritage, huh?
reread my first comment ;-)
And since all of this works just fine for atom boxes, I think this is a iemguis bug
the haven't been updated accordingly and I agree that they should.
it would be good to get rid of the #/$ substitutions. the problem is that it could break existing patches :-(. think of cases where a user would do something like [receive /foo/#1( and expected the #1 to be replaced with $1. (back then, it wasn't possible to type [receive /foo/\$1( ). maybe this would be the right place for a compatibility flag?
allowing "modern" dollarsyms in the properties dialog should be unproblematic, though.
the problem is that it could break existing patches :-(.
the #<->$ substitution is
because of that, i don't think we need to retain compatibility (not even with yet another stupid compat-flag (did i mention i don't like those compat-flags?))
so you if you don't have a problem with removing the #/$ substitution and bringing the dollarsym handling up to date, then let's do it! :-)
The #/$ substitution also seems to happen for atom boxes!
Setting a label of "C#" for an atom box becomes "C$", so I guess we need to fix this as well for them...
By the way, my main issue here is not being able to display labels correctly, which also happens for atom boxes
Most helpful comment
the
#<->$substitution isbecause of that, i don't think we need to retain compatibility (not even with yet another stupid compat-flag (did i mention i don't like those compat-flags?))