Re: [pollen] Question about Pollen markup
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 > 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
> lile 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
>>> 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 , and
>>> generally the generated markup is a bit weird – at each newline, a blank
>>> 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 .
> 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.
Re: [pollen] Question about Pollen markup
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
> 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
> lile 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 >
>> 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 , and generally the
>> generated markup is a bit weird – at each newline, a blank 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
> .
> 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.
Re: [pollen] Question about Pollen markup
Ah, my ◊comment's won't evaluate inside a ◊ol[…], so I guess there's that.
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
>> 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 , and
>> generally the generated markup is a bit weird – at each newline, a blank
>> 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.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
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 > 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 , and
> generally the generated markup is a bit weird – at each newline, a blank
> 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.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
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
> 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 , and generally the
> generated markup is a bit weird – at each newline, a blank 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.
For more options, visit https://groups.google.com/d/optout.
