That is incredibly helpful. Thanks so much for the tip. I was trying to do this very thing earlier.
Many thanks, for the help and the patience. Cheers, B On Wednesday, March 13, 2019 at 3:56:53 PM UTC-5, Matthew Butterick wrote: > > 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 <brendanst...@gmail.com > <javascript:>> 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 >>> >>> [2] >>> 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+...@googlegroups.com <javascript:>. > For more options, visit 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.