a bug? spaces are discarded / added (BfW 1.10)

[SlowThinker]

With BfW 1.10 this code

Code: Select all

{VARIABLE maximal_value 6}
[message]
	speaker=narrator
	message=Amount: up to $maximal_value
[/message]

shows

Amount:up to6

It looks ':' and '$' cause the problem.

The code worked correctly with BfW 1.8.

[8680]

Try message=_"Amount: up to $maximal_value".

[Anonymissimus]

What 8680 says.
The change in behavior of the engine is probably the same as the originally reported issue here: http://gna.org/bugs/?func=detailitem&it ... 92#options
(The decision was to won't fix it due to being negligible.)

[SlowThinker]

The change in behavior of the engine is probably the same as the originally reported issue here: http://gna.org/bugs/?func=detailitem&it ... 92#options

Hm ... is the link correct?

The decision was to won't fix it due to being negligible.

My view is very different. I believe any programming language should avoid exceptions and be as compact as possible ... and not only because of WML newbies.

------------------------------------
I ran some tests (1.10.1) and my observation is a bit different from the 8680's hint. The following statements may be true with BfW 1.10:

• The translation tag is not essential, only the quotes are essential
• any attribute whose value is not in the quoted form
  key="value"
  may be damaged
• $text "brings (invisible) quotes included", and so
  key=$var
  is safe

the test

Code: Select all

{VARIABLE maximal_value 6}

# this shows an incorrect text:
[message]
   speaker=narrator
   message=1 Amount: up to $maximal_value
[/message]
# this shows a correct text:
[message]
   speaker=narrator
   message=_"2 Amount: up to $maximal_value"
[/message]

# the translation mark is unecessary:
# this shows a correct text:
[message]
   speaker=narrator
   message="3 Amount: up to $maximal_value"
[/message]


# next macro and tag have an identical effect:
{VARIABLE text1 "11 Amount: up to $maximal_value"}
[set_variable]
	name=text1
	value="11 Amount: up to $maximal_value"
[/set_variable]
# now text1 contains '12 Amount: up to 6'
# this shows a correct text:
[message]
   speaker=narrator
   message=$text1
[/message]

# next macro and tag have an identical effect:
{VARIABLE text2 (12 Amount: up to $maximal_value)}
[set_variable]
	name=text2
	value=12 Amount: up to $maximal_value
[/set_variable]
# now text2 contains '12 Amount:up to6'

Anyway the fundamentals of the WML syntax have been changed with 1.10, at least next sentence is not true anymore:

a quoted value is a value surrounded by quotes. Note for single-line values this is completely unnecessary

**********************************************
Edit:
**********************************************

It looks the problem above may be solved if one puts all values in parenthesis, but it doesn't work in the following situation:
Spaces besides special characters are lost from parameters of macros:

Code: Select all

#define VARIABLE_MACRO VAR TEXT
	[set_variable]
		name="{VAR}"
		value="{TEXT}"
	[/set_variable]
#enddef 

{VARIABLE_MACRO var1 "- some text (content of parentheses)" } # it eats spaces: '-some text(content of parentheses)'

Is there any workaround for this problem?

an observation, not so important

This core macro doesn't eat spaces:

Code: Select all

{VARIABLE my_var "- some text (content of parentheses)" } 

--------------------------------------------------
Another change between the syntax of 1.8 and 1.10 is:
'+' adds a space

Code: Select all

{VARIABLE my_var wes+noth} # 1.8: 'wesnoth' 1.10: 'wes noth'

[8680]

I ran some tests (1.10.1) and my observation is a bit different from the 8680's hint. The following statements may be true with BfW 1.10:

• The translation tag is not essential, only the quotes are essential

Essential, no, but any string to be displayed to the user should be marked translatable.

Code: Select all

#define VARIABLE_MACRO VAR TEXT
	[set_variable]
		name="{VAR}"
		value="{TEXT}"
	[/set_variable]
#enddef 
{VARIABLE_MACRO var1 "- some text (content of parentheses)" } # it eats spaces: '-some text(content of parentheses)'

Wouldn't that expand to this?

Code: Select all

[set_variable]
    name="var1"
    value=""- some text (content of parentheses)""
[/set_variable]

[SlowThinker]

(edit: "Wouldn't that expand to this?" ... the question is answered further)

next code works well:

Code: Select all

#define VARIABLE_MACRO2 VAR TEXT
	[set_variable]
		name="{VAR}"
		value={TEXT}
	[/set_variable]
#enddef 

{VARIABLE_MACRO2 var1 "- some text (content of parentheses)" } 

-----------------------------------------------------
Now how to avoid this bug by following a simple rule? (like "always use quoted values" in case no macros are used)
A solution would be to use () in place of "":

Code: Select all

{VARIABLE_MACRO var1 (- some text - content of parentheses) # this works}

the problem is arguments couldn't use parentheses inside:

Code: Select all

{VARIABLE_MACRO var1 (- some text (content of parentheses)) # error: preprocessor symbol 'VARIABLE_MACRO' expects 2 arguments, but has 3 arguments}

[8680]

Now how to avoid this bug by following a simple rule?

Don't quote the arguments in the macro definition.

[SlowThinker]

I didn't quote the argument, but all the value.
In general the value must be quoted if one wants to avoid the bug.

[8680]

Code: Select all

## Macro definition.
#define SET_VAR NAME VALUE
[set_variable]
    name={NAME} ## Don't quote.
    value={VALUE}
[/set_variable]
#enddef

## Macro use. Arguments quoted where necessary.
{SET_VAR var1 blah}
{SET_VAR var2 "blah blah blah"}
{SET_VAR var3 _"blah blah"}

[SlowThinker]

Your method won't work here:

Code: Select all

#define VARIABLE_MACRO VAR ARG1 ARG2
	[set_variable]
		name={VAR} 
		value={ARG1} - {ARG2}
	[/set_variable]
#enddef

{VARIABLE_MACRO  var01 "( 1 )" "( 2 )" } # spaces around the hyphen are discarded: '( 1 )-( 2 )'

But surprisingly for me, next method works (at least in my tests):

Code: Select all

#define VARIABLE_MACRO VAR ARG1 ARG2
	[set_variable]
		name={VAR} 
		value={ARG1}" - "{ARG2}
	[/set_variable]
#enddef

{VARIABLE_MACRO  var02 "( 1 )" "( 2 )" } # works well: '( 1 ) - ( 2 )'

the method is:

• in the macro definitions, quote values, but skip all references to arguments
• in the macro "calls", quote arguments

(note: even if it will work in any situation, it is still quite awkward, and I would prefer if the bug was patched)

I was surprised that the code above worked well. I expected after the macro expansion the double-quotes would work like here:

Code: Select all

[set_variable]
	name=var03
	value="( 1 )"" - ""( 2 )" # works different: '( 1 )" - "( 2 )'
[/set_variable]

[SlowThinker]

I tried to verify the previous hypothesis...

Code: Select all

#define VARIABLE_MACRO VAR TEXT
	[set_variable]
		name="{VAR}"
		value="{TEXT}"
	[/set_variable]
#enddef 
{VARIABLE_MACRO var1 "- some text (content of parentheses)" } # it eats spaces: '-some text(content of parentheses)'

Wouldn't that expand to this?

Code: Select all

[set_variable]
    name="var1"
    value=""- some text (content of parentheses)""
[/set_variable]

... so I tested it (I created a save), and the answer is "no". It expands to

Code: Select all

[set_variable]
	name="var1"
	value="-some text(content of parentheses)"
[/set_variable]

This is really confusing, now I see no logic there ...
(still the "method" in my previous post might work)

[8680]

Maybe spaces are collapsed, then quotes are collapsed?

[SlowThinker]

Anyway the behaviour (spaces are / aren't discarded) depends on the position the argument is inserted to.

and I start to think studying effects of a bug is not very expedient ...