Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Handling the spaces produced in a multi-line if statement

I am using Sugarcube and I have an issue with the following code structure:
<<nobr>>
<<if $var1 neq "">>
You have a <<print $var1>>
<<else>>
You have nothing
<</if>>
<<if $var2 neq "">>
and you have an ally, <<print $var2>>, with you.
<<else>>
.
<</if>>
<<endnobr>>

In the case that $var1 equals "" and $var2 also equals "", the resulting sentence will look like this:
You have nothing .

The only way I've been able to get rid of that space between the "nothing" and the "." is to restructure the above code like so
<<nobr>>
<<if $var1 neq "">>
You have a <<print $var1>><<else>>
You have nothing<</if>><<if $var2 neq "">>and you have an ally with you.<<else>>.<</if>>
<<endnobr>>
but as you can see, that's quite unsightly.
Is there any more graceful way to prevent the if statement from generating that annoying space?

Comments

  • It can help if you state which version of SugarCube you are using, as the difference between them can influence an answer.

    It appears that you may of found a bug in the <<nobr>> macro and I suggest you create a new issue on the SugarCube repository, remember to state which version of SugarCube you are using.

    You can temporarily get around this issue by replacing the <<nobr>> macro with backslash based line-break escaping.
    <<if $var1 neq "">>\
    You have a <<print $var1>>\
    <<else>>\
    You have nothing\
    <</if>>\
    <<if $var2 neq "">>\
    and you have an ally, <<print $var2>>, with you.\
    <<else>>\
    .\
    <</if>>\
    
  • Sugarcube 1.0.34 in Twine 2, sorry.

    Also, I just tried that - Throwing a backslash at the end of each line did not seem to fix the issue. I still got the space. Perhaps it's not an issue with nobr?
  • That is strange because I did the following tests using SC 1.0.34 and your original code with backslashes instead of <<nobr>> and it produced the following outputs:
    1. <<set $var1 to "", $var2 to "">>
    
    You have nothing.
    
    2. <<set $var1 to "knife", $var2 to "">>
    
    You have a knife.
    
    3. <<set $var1 to "", $var2 to "Jane">>
    
    You have nothingand you have an ally, Jane, with you.
    
    4. <<set $var1 to "knife", $var2 to "Jane">>
    
    You have a knifeand you have an ally, Jane, with you.
    
    As you can see I actually needed to add an extra space to the start of the "and you have an...." line to correct a lack of a space issue with your original code.
  • edited June 2016
    Ah, my apologies.
    It turns out that tabbing your code like such
    <<nobr>>
        <<if $var1 neq "">>
            You have a <<print $var1>>
        <<else>>
            You have nothing
        <</if>>
        <<if $var2 neq "">>
            and you have an ally, <<print $var2>>, with you.
        <<else>>
            .
        <</if>>
    <<endnobr>>
    
    makes the program behave strangely.
    It interprets the tab before the "." as a space if and only if the last printed character was not a space. (For example, if you put a space after the "You have nothing", ie: "You have nothing ", there will be exactly one space between the "nothing" and the ".", but leaving it as "You have nothing" also results in exactly one space.) How strange.
    The solution was to remove all tabs AND use the backslashes. Less unsightly than having it all on one line with a nobr, but still not exactly what I would call graceful.
    Unfortunately, this solution does not work for nobr - Even if you remove all tabs, you get the space.

    Edit: I just installed and tested this on Sugarcube 2.6.2, and the bug is still present. I'll file an issue on the sugarcube page.
  • That is more an effect of HTML than of SugarCube, as HTML considers a tab character just another white-space character (like the space character is) unless it is within specific elements like pre and code.
  • That's not a bug, actually. It's simply how the macro works. Meaning that sometimes, yes, it doesn't do what you want.

    The <<nobr>> macro and nobr tag aren't one size fits all solutions, which is why the line continuation markup exists.
Sign In or Register to comment.