Closed pmenair closed 3 years ago
The return value of for-each
is always void
. Maybe you want map
?
(map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings in the REPL with \n's added and throws a error in the pollen server. ("Expected: txexpr-elements? Given: {a big s-expression that looks like my whole document}.") (map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids in the REPL. It produces a similar error in the pollen server. Looks like this is closer in that something is being inserted into the document that is making txexpr unhappy...
Can you paste a short example pollen source that triggers the problem and the resulting s-expression?
(map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings
You can’t return a list of X-expressions (for instance, strings) in a position that Pollen expects a single X-expression. You need to manufacture a new tagged X-expression with the list of X-expressions as elements. To do that, you can wrap the list, either with an HTML tag (like div
), or, if you really want the list to be merged with the surrounding material, with the special splicing tag @
.
(map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids
Right, because the return value of printf
is always void
. If you want to debug expressions, I suggest using the debug
language, which lets you print expressions without using printf
statements and disrupting the return value chain.
Works, sort of. Each string is formatted as " "~a: [~a] ~a \n\n"
◊(txexpr 'div '() agenda-dl) and ◊(txexpr 'div '() (decode-elements agenda-dl #:txexpr-elements-proc decode-paragraphs))
both give me the text without line or paragraph breaks. I'm guessing that the "\n\n" needs to be a separate element?
Yes. This is noted in the docs: “What counts as a paragraph? Any elements that are either a) explicitly set apart with a paragraph separator, or b) adjacent to a block-txexpr? (in which case the paragraph-ness is implied).“
FWIW, instead of embedding newlines in your strings and using decode-paragraphs
, you could just map
a tag function:
(require pollen/tag)
(map (default-tag-function 'p) '("string1" "string2" "string3"))
'((p "string1") (p "string2") (p "string3"))
FWIW the reason paragraph decoding works this way is so it cooperates nicely with the Pollen-style curly-brace notation, which returns a list of strings, with linebreaks separated from the other text elements. For instance markup written like so:
#lang pollen/mode racket
◊list{
first item
second item
third item
}
Results in this:
'("first item" "\n" "\n" "second item" "\n" "\n" "third item")
Notice that the leading and trailing whitespace is automatically trimmed, as well. Now we can take the output and pass it to decode-paragraphs
:
(decode-paragraphs '("first item" "\n" "\n" "second item" "\n" "\n" "third item"))
And get a list of three paragraphs:
'((p "first item") (p "second item") (p "third item"))
I have a list that I have made by consing strings from various places in a pollen document, called "agenda-dl." If I insert the tag
◊(for-each (lambda (x) (format "~a\n" x)) agenda-dl)
I can see the results formatted correctly in the REPL, but it does not appear in the html document. This does not appear to be an output port issue, because
◊(format "~a" agenda-dl)
puts me the unquoted strings in parens in the html without newlines, as expected. Is it not possible for a tag to walk through a list of strings in Pollen?