Here's how I debug Pollen functions. I have the `debug` package installed, and 
then I change my #lang line to

#lang debug racket/base 

(or `#lang debug racket` etc)

And then when I put #R in front of any expression, it prints to the Pollen 
console when a page is rendered. 

In this case, you could use `#R elements` to see exactly what's getting passed 
to your function. Or you could use `#R e #R (equal? e "\n")` to print `e` and 
the result of the predicate.




> On Mar 13, 2019, at 1:33 PM, Brendan Stromberger 
> <brendanstromber...@gmail.com> wrote:
> 
> Huh, I don't understand at all why, but for some reason, the code I just 
> posted above is now working. Maybe I inadvertently fixed some issue in the 
> template?
> 
> *shrug*
> 
> Anyway, thanks for the help, I think I understand working with xexprs a 
> littttttttle bit more now.
> 
> On Wednesday, March 13, 2019 at 3:18:03 PM UTC-5, Brendan Stromberger wrote:
> Is there a reason the curly-brace syntax is preferable? I've tried for the 
> past 2 hours but using filter-split on "\n" seems to have no effect on my 
> output. It seems more explicit to me to just use the ◊(ul[…]) form and not 
> have to do any mangling of xexprs. 
> 
> I think this is what you were suggesting?
> 
> (define (ul . elements)
>   (case (current-poly-target)
>     [(txt) elements]
>     [else (txexpr 'ul empty
>       (map (lambda (e) (txexpr 'li empty e)) (filter-split elements (λ (e) 
> (equal? e "\n")))))]))
> 
> On Sunday, March 10, 2019 at 8:22:40 PM UTC-5, Matthew Butterick wrote:
> The curly-brace syntax is almost always preferable. Keep in mind that the 
> linebreaks are separated into their own elements (For more on this behavior 
> see [1].) So this markup:
> 
> ◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
> another item
> another item
> }
> 
> Produces this list of five (not three) elements:
> 
> '("The remaining forty-nine stalks "
>              (comment "" ",")
>              " two piles."
>              "\n"
>              "another item"
>              "\n"
>              "another item")
> 
> Probably what you want is to preprocess `elements` into bigger chunks 
> representing list items before passing each to your 'li tag lambda. For 
> instance this:
> 
> (require sugar/list)
> (filter-split '("The remaining forty-nine stalks "
>              (comment "" ",")
>              " two piles."
>              "\n"
>              "another item"
>              "\n"
>              "another item")
>            (λ (e) (equal? e "\n")))
> 
> 
> Produces these sublists:
> 
> '(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
>   ("another item")
>   ("another item"))
> 
> For a more elaborate example of list-item detection, see the 
> `detect-list-items` function [2] in the pollen-tfl sample project.
> 
> [1] 
> https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
>  
> <https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29>
>  
> [2] 
> https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
>  
> <https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29>
>> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger <brendanst...@gmail.com <>> 
>> wrote:
>> 
>> Hey there, still plugging away on my book project. I have a function for an 
>> ordered list:
>> 
>> (define (ol . elements)
>>   (case (current-poly-target)
>>     [(txt) elements]
>>     [else (txexpr 'ol empty
>>       (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>> 
>> And I am using it like so:
>> 
>>     ◊ol[
>>       "The remaining forty-nine stalks are laid down and, aiming at the 
>> middle of the pile with the right thumb◊(comment "" ",") two piles are 
>> separated."
>>       "another item"
>>       "another item"
>>     ]
>> 
>> I want to use it this way because if I use the ◊ol{} syntax, my ◊comment{} 
>> tag in the first item gets treated as its own <li>, and generally the 
>> generated markup is a bit weird – at each newline, a blank <li> is generated:
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pollenpub+unsubscr...@googlegroups.com 
> <mailto:pollenpub+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to