Comments for Virtual Tags

[Messiaen]

In disturbingly eager anticipation of the 3.6 vtag-limit expansion...

Essentially the idea is to just allow C++ style comments to suffix virtual tag definitions to explain their what/why/how aspects to "my future self", such as why I chose to use an overly-complicated $If/$Contains/$Left/$Right combo instead of an overly complicated $RxMatch expression.  

Or, in particular, a very handy way of storing "alternate" regex expressions along the road to finding the one that works the best, and why.

$RxReplace(<Genre>,"(.*?),\s(.*?)$","$2 $1") // Swap comma-separated genre-sorting elements
$Pad($RxMatch($Div($Mod(<h.Work Duration>,3600),60),"\d+"),2) // Cleanup leftover minutes
<Work><Path> // Exclusion mask to stop grouping of Works by same Album Artists, etc...

I have many small "helper sub-function" tags which are used within more than one larger more complex tag, and creating clever names for these tags can only go so far, whereas an appended comment would allow me to instantly recall what other functions reference this function, and if it's ever even used (or still used) at all.

My future self thanks you for your consideration when he has to re-edit a tag a year from now that his brain-addled contemporary self concoted at 4am.  

[boroda]

+1, but maybe it's better to add new "tag comment" text box instead of inline comments?

[Messiaen]

I thought about that, but since most tags that might require a comment would have to be "expanded" first with the [...] button, having them inline makes more sense from a copy/paste point of view.  Unless the comment-box were in the expanded-editor to begin with, but that's more UI work, whereas inline can be implemented by simple truncation.

[boroda]

maybe you are right, but comments may be required mostly for complex v. tags, and implementing inline comments will make them almost useless without adding support for v.tag multi-line formatting (which has been asked too in the past).

[Messiaen]

Well, in a perfect world I'd ask for C-style /* ... */ inline commenting which is far more flexible and doesn't require multiline stuff, but does make things stranger to read for beginners and is harder to parse.  Also, any kind of inline text allows for people to copy/paste directly from a forum post without having to clean anything up.  <I do wish this forum had a "shrug" emogie>  

[hiccup]

$Noop("enter your comment here") seems to work?

[Messiaen]

From what rabbit did you pull that hat?  I like it (though the rabbit probably found it painful).  

You seem to have overlooked including that gem in your function compendium cheatsheet thingy?

[hiccup]

From what rabbit did you pull that hat?  I like it (though the rabbit probably found it painful).  
You seem to have overlooked including that gem in your function compendium cheatsheet thingy?

I was fooling around a bit, first trying this:
$If("a"="b","Put your comment here",)
which worked.
Then I thought to try $Noop(), since that can also be used for Picard scripts.  (it stands for no operation)

But I think the thing that makes this work is the $ alone. So you don't even need to add Noop behind it.
It will probably need some more testing though to see if it really works well.

[Messiaen]

...I think the thing that makes this work is the $ alone. So you don't even need to add Noop behind it.

Actually "$(hello world)" is quite a nice workaround/loophole/glitch.  In which case my wishlist request becomes "Please don't fix it!".  

The closest I came to anything useful in my tests was to stick with the "(?# comment )" used in inline regex, but obviously that only works in the $Rx-family of functions making them even more convoluted.

Thanks.

Edit: Come to think of it, how could the ability to allow accidentally mistyped function-names to just be ignored without throwing an error have existed this long without ever being noticed?

[hiccup]

Edit: Come to think of it, how could the ability to allow accidentally mistyped function-names to just be ignored without throwing an error have existed this long without ever being noticed?

Perhaps it would be proper to indeed have such a name check.
But then something like $Noop() will need to be added to the list.
(and to my cheat-sheet ;-)

[Messiaen]

Yeah, checking for proper labels, but just ignoring the complete lack of a label could remain as a comment (on the theory that any extra text is just clutter)... Noop (NOP) just gives me nightmares from my assembler mnemonic classes.  That said, alternatives like $Com would also give me API nightmares of a different sort.