Howdy, Stranger!

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

total white space collapse? possible [Feature Request: Harlowe]

I've been finding white space compression really useful in Harlowe, unfortunately it isn't strict enough to allow for clean code formatting.
For example I have this passage that changes a datamap value and prints a random reaction:

{
(set: $aloe's morality to ($aloe's morality -1))
<span class="description">
(either:
"Aloe glares at its soil, menacingly",
"Aloe lets out a high pitched evil giggle")
</span>
}
Used like this:

Haha, yes, people ARE worthless!!
(display:"aloe-reaction-evil")
This compresses the spaces before and after each line, leaving three unwanted spaces before the reaction.

Is there a way to combat this without eliminating all line breaks? If not I think there would be great value in having a macro that eliminates all whitespace. That way you could set multiple variables and format your code nicely without worrying about unwanted spaces.

What do you think?

Comments

  • Wish I were replying to provide an answer but I was actually just looking for the same thing... so thought I'd chime in and bump the question.  I have:
    Height: .{
    (set: $actionSwitch_01 to "height")
    (set: $inputInt_01 to $player_height)
    (display: "lng_bodyDescription")
    }.
    where lng_bodyDescription starts with { and everything is contained within } and no spaces beyond that.  My output is:
    Height: . Average .
    So about 8 spaces between the first dot at the beginning '.{') and the second dot (at the end '}.'  Guessing I am getting more spaces because there are other { } - not nested in the same area but included in the thing that gets displayed...

    So.... bump?  :)
  • There is a complication or a processing order issue with just removing all space (like) characters because the new-line symbol at the end of each line is converted into a space character and therefor could end up also being removed.

    The following two examples both result in The quick brown fox, note the inserted space character between quick and brown

    {
    The quick
    brown fox
    }

    {
    The quick
    brown fox
    }
    This is what is happening in sammyt (and maybe Noctifer) example, the single extra space character between the end of the first </tw-expression> tag and the start of the <span> tag, and between the same <span> tag and the second <tw-expression> tag are more than likely the result of the new-line symbols being converted into space characters.
  • That sounds quite possible / reasonable, especially if the check for continuous white spaces is being done before the actual conversion of the characters to white spaces instead of the other way around (since \r and \n are not the same ascii code as a white space)

    I just did this real quick
    Height: .{(set: $actionSwitch_01 to "height")
    (set: $inputInt_01 to $player_height)
    (display: "lng_bodyDescription")
    }.
    and the output of that was:
    Height: . Average .
    Then I went into the lng_bodyDescription function and cleared away most of the new lines and got it down to 
    Height: . Average .
    Then for good measure I went in and within the { } I commented out all the new lines and white spaces manually..
    {<!--
    Desc: Returns a height word based on some height lvl: $inputInt_01
    Sample Use:
    (set: $actionSwitch_01 to "height")
    (set: $inputInt_01 to $player_height)
    (display: "lng_height")
    Output:
    A word description, eg 'slim', 'curvy'


    -->(if: $inputInt_01 is false)[<!--
    -->$errorText[Error(**f lng bodyDescription**). Attempting to use inputInt01 without setting it]<!--
    -->]<!--
    -->(elseif: $actionSwitch_01 is "height")[<!--
    -->(if: $inputInt_01 < 5)[Short]<!--
    -->(elseif: $inputInt_01 < 7)[(either: "Average")]<!--
    -->(else:)[Tall]
    .... and so on
    And that's brought it down to
    Height: . Average.
    Eh, anyway, minor annoyance for formatting pretty code along-side pretty-text but not a show-stopper or anything.  If it is just a known issue then that's fine (far as my stuff goes anyway), can always manually or scripting-wise strip out newlines in my code for release-versions and just keep them for my own work.  Just wasn't sure if I was using the proper / intended tool. 
  • One thing I forgot to point out is the Harlowe CSS on the tw-passage element that is causing those extra spaces to look the way they do.

    tw-passage {
    white-space: pre-wrap;
    }
    Using sammyt's example as a base, if you temporally change the white-space property to its default value you will see that the space character at the start of the "Aloe glares" line is not displayed.

    tw-passage {
    white-space: normal;
    }
    note: Changing the white-space property can effect how other things are display within a passage.
  • Hi again! Yay - the white space thing was starting to cause problems so I went back to this and saw the new reply.  Much happiness except... I don't think I'm using it right at all?  It sounds like this is something I should be able to just add into the code
    tw-passage {
    white-space: normal;
    }
    {(display:"someQuasiFunctionBeingCalledThatReturnsText")}
    tw-passage {
    white-space: pre-wrap;
    }
    buuuut... it just seems to add the words:
    tw-passage white-space: normal;
    before what's being returned.  http://twinery.org/forum/index.php?topic=2094.0  suggests css isn't really implemented yet in Harlowe, http://twinery.org/forum/index.php?topic=1528.0 suggests that it is (but it doesn't seem to work).. is there a special place only that I'm supposed to add that?  Would be quite nice to get rid of white space, its making randomized sentence generation a bit of a pain to look at the more I work with this.  :-[
  • This is because you are trying to add CSS rules directly to your passage and CSS rules belong in your Story Stylesheet, accessed by selecting the correct option in the menu displayed when you click on your story's name displayed in the lower left corner.

    The second issue is if you want the white-space: normal property to be only applied to some content then your going to have to mark that content in a way that CSS can find it.
    note: the choice to use either a <div> or a <span> depends on the content being returned by your (display:)
    eg.

    <div class="compress">
    {(display:"someQuasiFunctionBeingCalledThatReturnsText")}
    </div>
    You could then add a CSS rule like the following within your Story Stylesheet to only change the white-space property for that content:

    tw-passage .compress {
    white-space: normal;
    }
    One further complication is that the {} feature has been changed in the 1.1.0 version of Harlowe and works differently, exactly how differently wont be known until it is released. lol
  • Ohhhhhh that was the missing piece - didn't know about the stylesheets in there, thought it was embedded more deeply somewhere and we just over-rode them per-passage.  Perfect, that brings it down to just one extra space each, I can live with that!  (CSS has ever been the bane of my existence, I'm happier to code in C/C++ than trying to get CSS/HTML/Javascript to all pretend like they're talking in the same language ;))

    Hopefully the upcoming version's tweaks make this un-necessary rather than requiring a different fix.  :)

    Thanks greyelf, you totally rock!

Sign In or Register to comment.