I've studied the scripting functions, and the only place a square bracket is significant is within a regular expression. Regular expressions are only usable inside the action "Replace with regular expression".
Outside of that specific action, square brackets should not be treated as special characters. I assert that we have a bug here, and request this thread be requeued.
Read this: Mp3tag Help / Scripting functions
... at the end of the page
Characters with special functionality
[...] The contents of brackets are displayed only if at least one of the placeholders used inside the brackets has been found.
The square brackets have a special significance (as an inline function) in the scripting area of Mp3tag. It is not a bug, but a documented feature. Many scripts rely on this feature.
At the beginning this usage of square brackets was difficult to understand, later on I have internalized this functionality, but I do not like the fact of escaping square brackets within a regular expression. This makes the Mp3tag $regexp() function a bit obscure. If you use the related RegExp replace action, then there is escaping not needed.
I tend to say that the Mp3tag scripting language is not a perfect language, even not syntactically correct in all cases, and it has quirks by design (historical grounded), but it is an outstanding working vehicle and it does it's job quite good. For some users Mp3tag will appear as 'caves bad', but for other users as 'super good'.
It could be even better when opening the programming sources resp. have a team of developers, each with special abilities in different IT areas e. g. application designing, programming logic, coding, GUI, syntax, documentation, user support and so on. It is not so easy to shoulder and to unite all of these functions for one person.
Please define "placeholders" in the context of the above.
Even more interesting would be a pointer to a script that uses square bracket syntax.
/pleading voice on
I've been programming professionally for 30 years and have seen virtually everything programming/script languages can do, so documentation is normally just a "OK, they chose to do it this way" thing.
But occasionally the MP3tag documentation doesn't even give me a clue about how something might operate -- not even enough to try coding some examples to see what happens. Action 'Split fields by separator' is one the comes to mind immediately... (And I suspect 'Guess Values' may be a functional replacement?)
I don't expect that many many items in the documentation provide enough information for non-programmers to see the idea floating inside the developer's head when the item was coded.
And searching the forums for
"example" AND ""
doesn't find anything for much beside the most basic. IMHO, just adding a example to each item in the documentation would be a fantastic learning aid!
Hmm, you are right, having the view and experience as a programmer. But you should take into account, that in the domain of tagging music files there are many historical based traditional quirks, even in other tagger applications, how to show, use, manipulate tag content. There is another way of thinking.
Well, documentation is a steady process, and it is not so easy to make it complete and understandable for all levels of user knowledge, but the content has been grown better over the years.
It is still a problem how to support both sides of the weighbridge "I write my own tagger tool in my free time" and "I am a lonesome programmer but want to write a tager tool for the masses world wide".
JMThomas, try to use the Mp3tag tool as is, write your bug reports, offer workarounds, push new requests, share your insights with other users, and have good hope that this Mp3tag tool will survive you.