Up to Main Index                             Up to Journal for March, 2019

                     JOURNAL FOR SUNDAY 31ST MARCH, 2019
______________________________________________________________________________

SUBJECT: Now I remember…
   DATE: Sun 31 Mar 19:43:20 BST 2019

In my last entry I wrote:


  “When writing WolfMUD’s recordjar package I tried to be clever. Never bodes
  well does it? I think I’m starting to see a pattern here. I though it would
  be a good idea to only preserve meaningful white-space. This works well.
  Until WolfMUD reformats all outgoing text using the text.Fold function that
  is, then the extra effort is wasted. More importantly, should reading a jar
  file be monkeying around with your carefully crafted text in the first
  place? I have come to realise it should not.”


Never bodes well indeed. While working on my little static site generator I
needed to fold some text for the abstracts used on the index pages. I used
WolfMUD‘s text.Fold and it broke. It simply would not fold the text properly
and it took me ages to work out why.

The line I was trying to fold from 80 columns to 70 columns was:


  A report on MUDs from December, 1990. Written by Dr Richard Bartle of MUD1
  fame. An interesting read into the past.


What I wanted, and what I expected to get was:


  A report on MUDs from December, 1990. Written by Dr Richard Bartle of
  MUD1 fame. An interesting read into the past.


What I ended up with was:


  A report on MUDs from December, 1990. Written by Dr Richard Bartle of
  MUD1
  fame. An interesting read into the past.


What the hell? I ran all of the recordjar and text package tests, everything
passed. I then spent hours debugging and pulling everything apart.

The problem turned out to be due to the fact that text.Fold only folds text,
but it does not unfold the text first. The unfolding of the text had been
performed when reading the Jar and ‘only preserving meaningful white-space’.

For example. Assume we have the following text:


  This is a
  split line.

  This is a split line
  after a blank line.

    This is an indented
  split line.


If we only preserve meaningful white-space, so that we can fold the text later
to fit any width, we end up with:


  This is a split line.

  This is a split line after a blank line.

    This is an indented split line.


The blank lines are preserved as is the indent. Preserving only meaningful
white-space in text like that is quite simple. However some of the odd, corner
cases are a pain. For example:


  \x1b[32m  An indented green line.


Here we have an indented line, but it has the prefix ‘\x1b[32m’ which is the
escape code to make the line green. The prefix is invisible and has a zero
display width. It is expected that the indent be preserved in this case.

I tried to enhance text.Fold to unfold text, before folding it, and the code
became horribly complicated. I tried unfolding the text while folding it,
again horrible code. I tried to implement a text.Unfold, but that kept failing
on odd corner cases. It seems the best course of action would be to add the
unfolding back into recordjar.Read, but I really don’t like that idea :(

For now, I’m still working on my preferred solution of having a text.Unfold
that handles all corner cases. WolfMUD can then read all of the zone files
once, unfold all of the free text sections once, and then fold it to any width
needed as often as needed.

I find playing with text — folding, unfolding and formatting — an interesting
area of programming for problem solving. I spent a lot of time on WolfMUD’s
text.Fold function. Plain ASCII text is quite simple to handle. However, throw
in multi-byte Unicode, non-spacing and enclosing marks, combining marks,
escape sequences and other non-printing formatting sequences and things tend
to get a lot more interesting.

If you have not read it already, please take a moment to read one of my
previous entries 22.html — your time is greatly appreciated.

--
Diddymus


  Up to Main Index                             Up to Journal for March, 2019