Hi Ties,

I've looked into this a little more and here is what I think is happening: CL-Markdown uses my containers library (CL-Containers) and, in particular, the iterator constructs. These let me create an iterator and use it without caring about where the data originates because the iterator is supposed to abstract all of that out. So the call in chunk-source can look like:

(with-iterator (i source :treat-contents-as :lines :skip-empty- chunks? nil) (iterate-elements i (lambda (line) (chunk-line line))))

where source can be a string or a pathname. The with-iterator macro eventually turns into a call to make-iterator and make-iterator uses the arguments it is supplied to construct the appropriate class and instantiate it. in particular, if source is a pathname, the iterator will be of type 'file-line-iterator; if source is a string, you'll get a 'line-iterator. The line-iterator is a subclass of delimited iterator and uses #\linefeed, #\newline (and now #\return) to find lines. On OS X, this code

(list (char-code #\linefeed) (char-code #\newline) (char-code # \return))

return various things in various Lisps:

(MCL) ==> 10 13 13 (SBCL 0.9.11) ==> 10 10 13 (OpenMCL) ==> 10 10 13

So if one of your strings had switched to #\return's instead of # \linefeed or #\newlines, then this is probably what caused the problem. I'm adding #\return to the list of delimiters for the line- iterator so that should correct this problem.

Note that the file-line-iterator uses read-line to suck in each line. This means that the changing the delimiter won't have any effect on files. It also means that the line ending in files will be significant to CL-Markdown (i.e., CL-Markdown won't work correctly if read-line doesn't read lines <smile>).

HTH, please keep me informed as to any more trials and tribulations you encounter (and successes too!)

On Jun 9, 2006, at 3:59 PM, Ties Stuij wrote:

Eureka! i got it.

...

So are you saying that

? (markdown "..." :stream t)

works but

? (markdown "..." :stream "/my/file/name/here")

fails?

No i store two strings in elephant class slots: the markdown text and the output of the markdown. Since elephant only references slots you ask for, this seemed to me to be the most efficient way to use it. If you want to update the text you can edit it in place through a form (we're talking browsers here).

Anyway, it turns out that get?/post?/the browser?/ucw? saves line-jumps as returns in stead of newlines. Something a newbie like me doesn't think about so fast. I solved it in my app by regexp-replacing through the string. I was gonna supply a patch but i noticed your code decides on a low (container) level if the text you want to process is a string or whatever, so i don't really know what is the preferred route.

Btw, while on my bughunt i installed through asdf-install and noticed it installed a couple of dependencies that were not needed with the darcs markdown, eg trivial shell, lml2, lift, cl-html-diff and cl-difflib. You probably knew this and it is no biggie but you never know.

Anyway, thanks for the help,

Greets, Ties