$VERSIONINFO enhancement (#20)

[a740g]

This PR implements $VERSIONINFO enhancement as described in #20.

This works in a backwards compatible way which allows the old behavior but also suggests the user (via warnings) to enclose the strings using the string bracket delimiter ''.

• Allows old behavior
• FILEVERSION# and PRODUCTVERSION# are exempted
• Honors warning setting - Options > Ignore Warnings

Warning messages for current qb64pe.bas $VERSIONINFO:

Closes #20.

[RhoSigma-QB64]

Shouldn't this PR not do the required adjustments in qb64pe.bas to avoid those warnings?

[a740g]

Shouldn't this PR not do the required adjustments in qb64pe.bas to avoid those warnings?

We can wrap the $VERSIONINFO strings in quotes in q64pe.bas so that it does now show these warnings. Even if we leave them the way they are, nothing will break.
I am ok adding the quotes if everyone is ok. It'll save another PR down the line.

Did I even understand the question correctly? 🙂

[RhoSigma-QB64]

For me it's unclear why we need to throw warnings at all, if both methods (w/ and w/o quotes) are valid and allowed? But, if we want warn about missing quotes, then we should clean our own house, making sure we don't get warnings on our own code. Just a matter of my sick perfectionism I guess :)

[a740g]

For me it's unclear why we need to throw warnings at all, if both methods (w/ and w/o quotes) are valid and allowed? But, if we want warn about missing quotes, then we should clean our own house, making sure we don't get warnings on our own code. Just a matter of my sick perfectionism I guess :)

Ah. Ok. I get it. And you are right.

I added the warnings because that's what #20 suggested. And TBH, adding warnings does seem a little useful. Without the quotes the IDE attempts to syntax-highlight the string which ends up looking ugly. The warning basically motivates the user to add the quotes.

Fun fact: When I first started using QB64, I always used to add the quotes to the $VERSIONINFO strings thinking that was a natural thing to do.

I am good both ways:

1. We can drop the warnings completely, or
2. We just add the quotes to clean our own house

[RhoSigma-QB64]

Without the quotes the IDE attempts to syntax-highlight the string which ends up looking ugly. The warning basically motivates the user to add the quotes.

Yeah, noticed that too when implementing the code export stuff, but it's rather a matter of finetuning the syntax highlighter then. I already did that for the code export to avoid this faulty highlighting. I can look at the IDE highlighter later, for now I'd say just clean our house :)

[a740g]

Without the quotes the IDE attempts to syntax-highlight the string which ends up looking ugly. The warning basically motivates the user to add the quotes.

Yeah, noticed that too when implementing the code export stuff, but it's rather a matter of finetuning the syntax highlighter then. I already did that for the code export to avoid this faulty highlighting. I can look at the IDE highlighter later, for now I'd say just clean our house :)

Done.

[RhoSigma-QB64]

BTW in #20 Matt mentioned that by his knowlegde $VERSIONINFO was the only Meta-Command which allows unquoted strings, but I know at least one other, it's $ERROR, maybe you want to look at that too and fix it in the same run.

What's about $LET, can we define a string such as $LET me = RhoSigma? Must admit I avoid the pre-compiler till now.

[a740g]

BTW in #20 Matt mentioned that by his knowlegde $VERSIONINFO was the only Meta-Command which allows unquoted strings, but I know at least one other, it's $ERROR, maybe you want to look at that too and fix it in the same run.

What's about $LET, can we define a string such as $LET me = RhoSigma? Must admit I avoid the pre-compiler till now.

Fair callout on $ERROR. I'll get that to be compliant as well.
I usually use $LET to create per-processor variables and seldom assign any string values. It however requires strings to be properly quoted using " if you are assigning one.
While on the topic, $MIDISOUNDFONT seems to require " instead of '. I am not sure if this is intentional and requires any change. 🤷‍♂️

[a740g]

Enabled $ERROR to handle strings enclosed using '' as suggested by @RhoSigma-QB64.

[RhoSigma-QB64]

With your new FUNCTION RemoveStringEnclosingPair() you may want to check its usability for '$INCLUDE: 'file.bm' too have not several different handlings for several meta-commands.

[a740g]

With your new FUNCTION RemoveStringEnclosingPair() you may want to check its usability for '$INCLUDE: 'file.bm' too have not several different handlings for several meta-commands.

I looked at the $INCLUDE handling here and it seems like there is special handling been done due to this metacommand being embedded in a comment and some QB45 behavior. It does mandate usage of ' to enclose file names. This is part of the giant lineformat$() function. IMO, it is best we leave it the way it is and re-visit it sometime in the future as part of a significant compiler re-write / simplification.