[Chicken-users] stream-wiki doesn't like CR/LF's, etc.

[Shawn Rutledge]

The problems I was having were mostly due to this - when using a
textarea in a browser, the text that comes back has CR/LF's instead of
just LF (and I'm using Firefox on Linux so didn't expect that). 
#\newline doesn't match the CR's, so they are in the way.  I fixed it
for now by hacking the remove-comments function like this:

(define (remove-comments str)
  (parse-all
    str
    (lambda () (error "noparse"))
    (lambda (str fail parsed)
      (parse-token-simple str
        (("<!--" (*? char?) "-->") stream-null)
                ((#\return) stream-null)
        (((bind c char?)) c)))))

so it simply trashes all the CR's before doing the usual wiki parsing.
 Now I hope it doesn't turn out that Mac browsers send only CR's and
no LF's, or something like that.  :-)

The way this parser is written, it's important to have a blank line before a
== heading ==
otherwise it will become part of the paragraph above it.  It's
difficult to change that behavior without also prohibiting a normal
paragraph from starting with an equals sign.

Finally I modified the <hr> rule like this

      ((#\- #\- #\- (+all #\-) (all char-blank?)) (html-stream (hr)))

so that 4 or more hyphens on a line by themselves generate an hrule
(as it was, you had to have exactly 4, and any extras would become
actual hyphens (or em or en dashes depending on the quantity) after
the <hr>, which seems silly to me).

For [[toc:]] I'm getting an empty string so will investigate that next.